db-ui / core Goto Github PK
View Code? Open in Web Editor NEWTechnical Frontend implementation of the DB UX Design System (successor of DB UX & EDS Guidelines)
Home Page: https://db-ui.github.io/core/
License: Apache License 2.0
Technical Frontend implementation of the DB UX Design System (successor of DB UX & EDS Guidelines)
Home Page: https://db-ui.github.io/core/
License: Apache License 2.0
We're actually setting the node version for local development by .nvmrc
, but not within the pipelines, which might result in unexpected problems.
This is most likely relevant for each dependent ci/cd helper we're using e.g. for installing dependencies, compare to https://github.com/bahmutov/npm-install#node-version
Previously we had an alphabetical order, which doesn't feel right for all of us. We'd instead like to have some logical ordering and should evaluate for a new stylelint plugin on this.
Especially changes/simplifications out of feat: skip install if $HUSKY=0
:
https://github.com/typicode/husky/releases#:~:text=feat%3A%20skip%20install%20if%20%24HUSKY%3D0
the background and on colors contrasts for warnings and information are slightly too low.
Evaluate to use :user-invalid
instead of :invalid
within our code base, as this is actually the expected behaviour by our creative colleagues, as soon as it lands and is stable in the evergreen browsers:
We'd like to mention aspects like e.g. our CONTRIBUTION
guidelines and aspects someone should check before UI contributions like e.g. emulating forced-colors
, prefers-colors-scheme
(probably we mention those in an extra document, that we even also link from the CONTRIBUTION
file.
As already mentioned with db-ui/mono#152 some PRs have been merged (automatically) even though that the linting step failed.
We should set up an example with an horizontally scrollable table component with an included overflow-menu component, which is currently being reported to get cut off.
Currently we're having two sections for contributions within our README file – we should most likely merge this to one, and even also extract relevant information to the separate CONTRIBUTING.md
file.
That file would additionally need some more rework, as we're currently mentioning the husky dependency, but especially for somebody new to the project don't mention how they should do this, as in general this dependency would get installed by the general npm install
:
https://github.com/db-ui/core/blob/main/CONTRIBUTING.md?plain=1#L9
Besides that we should mention some prerequisites like e.g. nvm
that would ensure the expected node version to be installed.
Per request we should evaluate whether we even already hide the standard-browser-styles cancel icon, that is specifically defined for search input types, like e.g. by the following declarations:
https://stackoverflow.com/a/18856343
We should compare to the Design System documentation and align with the UX colleagues first.
Move the Base parts of the DB UI Core documentation to DB UI Base to remove the redundant documentation parts and link to those pages afterwards out of DB UI Core.
We're not sure if this is the intended behavior: an input with label and placeholder that is marked as required and empty will never be styled as invalid because the invalid rule is restricted to :not(:placeholder-shown)
. We would argue that placeholders are intended to indicate what should be entered into a field and not that the field is optional.
Better document both that we render incremental component css files, as well as how to use them as well as the necessary global css (node_modules/@db-ui/core/dist/css/db-ui-core.general.css and node_modules/@db-ui/core/dist/css/db-ui-core.vars.css) within ones project, as well as which SCSS to customize if necessary:
$icons-path
(default: "../../icons/"
)$images-path
(default: "../../images/"
)$fonts-path
(default: "../../fonts/"
)Related to db-ui/elements#307 & db-ui/base#69
Evaluate on a11y, as this pattern might not correctly get read out by screenreaders:
https://db-ui.github.io/core/patterns/elements-chips/index.html
We most likely need to adapt the aria-labelledby
attribute for the input
element as included within the input pattern.
The following changes will be part of the Guidelines 3.0 to the button element:
background-color
should change on hover hover with a transitionBrand primary
becomes the regular Primary
buttonPrimary
becomes Secondary Inverted
Secondary Outline
becomes Secondary
Secondary Solid
becomes Tertiary
Tertiary Plain
becomes Ghost
Hover
and Pressed
states (Secondary
, Tertiary
and Ghost
types) have been refactored to 12% for Hover
and 24% for Pressed
XSmall
sizeXLarge
and XXSmall
sizesregular
size to medium
FullWidth
CHANGELOG.md
entries, both for prereleases (underneath Unreleased
at the beginning) as well as in a hidden (by comment) summary at the beginningdocs/migrationGuide.adoc
.pa11yci
and tests/backstop.json
There are some fonts in https://github.com/db-ui/base/tree/main/assets/fonts (dbscreenhead-regular, dbscreensans-medium, dbscreensans-semibold, ...) which are not converted to CSS definitions of those fonts (see https://github.com/db-ui/core/blob/main/source/_patterns/00-base/type/_fonts.variables.scss).
Is there a reason for this mismatch?
what about moving those to DB UI Base ?
Originally posted by @mfranzke in #89 (comment)
begin
(default) & center
headline
element the following two are optional to get added:
body text
button
Follow up for previous redesign work:
Reference: Zeplin, Slide Interactive Color Layers
DB Red
default: #EC0016
hover: #CF0013
pressed: #B00010
Grey
default: #282D37
hover: #3F4757
pressed: #556075
White
default: #FFFFFF
hover: #E0E0E0
pressed: #C2C2C2
Light Grey
default: #D7DCE1
hover: #B9BDC2
pressed: #9CA0A3
Darker Grey
default: #646973
hover: #494D54
pressed: #2F3136
Transparent (on Light)
default: rgba(40,45,55,0.00)
hover: rgba(40,45,55,0.12)
pressed: rgba(40,45,55,0.24)
selected: rgba(40,45,55,0.36)
Transparent (on Dark)
default: rgba(255,255,255,0.00)
hover: rgba(255,255,255,0.12)
hover: rgba(255,255,255,0.24)
pressed: rgba(255,255,255,0.36)
Medium Grey
default: #878C96
hover: #6C7078
pressed: #505359
DB Red
default: #EC0016
hover: #D90016
pressed: #C40012
Grey
default: #282D37
hover: #383F4D
pressed: #464F61
White
default: #FFFFFF
hover: #EBEBEB
pressed: #D6D6D6
Light Grey
default: #D7DCE1
hover: #C3C7CC
pressed: #AFB4B8
Darker Grey
default: #646973
hover: #52565E
pressed: #40444A
Transparent (on Light)
default: rgba(40,45,55,0.00)
hover: rgba(40,45,55,0.08)
pressed: rgba(40,45,55,0.16)
selected: rgba(40,45,55,0.12)
Transparent (on Dark)
default: rgba(255,255,255,0.00)
hover: rgba(255,255,255,0.08)
pressd: rgba(255,255,255,0.16)
selected: rgba(255,255,255,0.12)
Medium Grey
default: #878C96
hover: #757982
pressed: #63666E
The other repositories even already provide review
folders, so we should adapt this to DB UI Core as well.
Currently, when a disabled form control or button contains HTML elements (for example, icons or span
s for internationalization), clicking on that part of the content is not actually disabled. That means, disabled submit buttons actually submit forms.
We used an override with pointer-events: none
to circumvent this behavior. To my knowledge, this rule is common in other UI frameworks. Could it be added to Core?
Our override:
db-button, button, db-select, select, db-input, input {
&[disabled] {
pointer-events: none;
}
}
The following changes will be part of the Guidelines 3.0 to the checkbox element:
required
stateCHANGELOG.md
entries, both for prereleases (underneath Unreleased
at the beginning) as well as in a hidden (by comment) summary at the beginningdocs/migrationGuide.adoc
.pa11yci
and tests/backstop.json
As a follow up to #218 let's migrate all of the previous implementations
The following changes will be part of the Guidelines 3.0 to the radio element:
required
stateCHANGELOG.md
entries, both for prereleases (underneath Unreleased
at the beginning) as well as in a hidden (by comment) summary at the beginningdocs/migrationGuide.adoc
.pa11yci
and tests/backstop.json
Modularize the different steps and cache the artifacts
Currently h5 and h6 are not defined by styleguide v2.x. Shouldn't we provide fallbacks in case of users add h5 or h6 tags on their page? (E.g. font size Body 1 with font-weight bold).
As a follow up to #17 we'll provide the DB Screen Sans Digital Regular definitions from now within the @font-face
declarations, but don't reference them at the moment.
see also db-ui/mono#396
The following changes will be part of the Guidelines 3.0 to the textfield element:
CHANGELOG.md
entries, both for prereleases (underneath Unreleased
at the beginning) as well as in a hidden (by comment) summary at the beginningdocs/migrationGuide.adoc
.pa11yci
and tests/backstop.json
In case of any changes to the target branch we might need to tell dependabot to rebase it's pull request. With a huger amount of PRs, this might get a time consuming task, so we should look into this whether we could automate this task.
Candidates:
At the moment, all icons receive a small amount of right margin, which is very helpful when they're placed in front of text.
However, in some situations, there is no text afterwards and the margin causes a weird look. In Core, for icononly buttons and similar (but not all) use cases, there's styling to reset the margin to 0. This isn't applied in Elements though, because icons use the shadow DOM there.
I would love an additional attribute like data-icon-margin
with values default | none
or similar to enable users to remove margin whenever needed.
Opening issue in Core because the general option to remove margin might be relevant to many, regardless of framework. Let me know if I should open in Elements instead.
Either replace or prepend all existing namespaces of elm-
/cmp-
/rea-
(and possible future tpl-
for templates, all of which inform the users of their types) by another namespace (e.g. db-
).
As a follow up to #198 we need to provide the following pattern variants:
type number
type date
type datetime-local
type week
type month
discuss pointer-events: none for label
Even also evaluate whether to include span.elm-state-icon
within the description.
why do we mix language values here? Shouldn't we leave it in german as default?
We should decide whether we provide both language versions and/or only one of them (translate the "Datenschutzerklärung", or link to the german imprint).
Originally posted by @annsch in #270 (comment)
The following changes will be part of the Guidelines 3.0 to the link element:
tbd
CHANGELOG.md
entries, both for prereleases (underneath Unreleased
at the beginning) as well as in a hidden (by comment) summary at the beginningdocs/migrationGuide.adoc
.pa11yci
and tests/backstop.json
Replace the sample images with solely produced images by ourselves:
https://unsplash.com/de/fotos/-UZa949e8LE
adapted from db-ui/base#82 and db-ui/base#83
Buttons sollen im Disabled State nicht mehr pauschal den grauen Farbton erhalten, sondern in Anlehnung an die 3.0 Library gestaltet sein.
Das bedeutet, dass der initiale Button erhalten bleibt und der disabled Zustand mittels Transparenzen visualisiert wird. Diese Logik überträgt sich auf alle vorhandenen Buttons.Akzeptanzkriterien
- Flächen
Die Hintergrundfläche werden mit 25% Opacity als disabled dargestellt- Rahmen
Rahmen werden analog zu Flächen behandelt und werden mit 25% Opacity als disabled dargestellt- Text & Icon
Text und Icon werden mit 50% Opacity als disabled dargestelltBeispiel und Hinweis
Es kann nicht pauschal mit einer Opacity auf dem Button gearbeitet werden, da die Elemente im Vordergrund (Label & Icon) anders gehandhabt werden als der Hintergrund.
see also internal ticket no. DBSWC-881
I'm wondering whether we should probably include the transition property (`color`) in here as well (and/or in DB Base code already). Currently the transition property is not included in this declaration and that might mean that all CSS properties would get animated (which is not what the variable name implies).
Originally posted by @mfranzke in #89 (comment)
Within the select pattern we're include a quite generic label as well as option values directly within the code. Additionally we should align the different <option>
tags value-attributs, currently only one of them includes a value
-attribute.
https://github.com/db-ui/core/blob/main/source/_patterns/01-elements/select/_select.hbs#L9L12
https://github.com/db-ui/core/blob/main/source/_patterns/01-elements/select/_select.json#L3
Resolved by #21
As mentioned by @shartte within db-ui/base#252, while committing some markdownlint
errors come up. These weren't shown on MacOS environments, but could get fixed by quoting the globs:
https://github.com/igorshubovych/markdownlint-cli#globbing
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.