Febakke
commented
3 months ago Meeting 16.04
- [ ] Create a sketch on new semantic tokens structure
- [ ] All categories have same values
- [ ] Create new color scales
- [ ] Test with linear scale
- [ ] Radixlike overview of colors and uses
- [ ] Create new tokens
- [ ] Rename action to accent
- [ ] Define semantic rules on when to use accent colors
- [ ] Remove action second variant of button
- [ ] Change tokens on button and other components to use accent/action from semantic
- [ ] Remove first and second action tokens
Form components
- Default: Grey color (not changed by accent color)
- Hover: light version of accent color
- Active/selected: Accent color
- Pressed (button only?)
- [ ] Define system for how to set this up. For example when you have a dark accent color where hover will be harder to see if it is a darker version.
Link
- Link should use accent colors
Focus
- [ ] Test with accent color or text color
Spinner
- Use accent color
Helptext
- Use accent color
Accordion
- Use accent on default open
Darkmode
- [ ] Test switching between light and dark mode on different accent colors
mrosvik
Prepare for theming and mode support
To support dark mode and contrast mode we should prepare our tokens structure before the V1 release, since this will change the underlying tokens structure and generate some breaking changes. Colors should be rearranged into "Light", "Dark", "Contrast" sets. Also, tokens should not have names containing "light" or "dark". We have to investigate which inverted colors that still has meaning, and which will be replace by dark mode support.
In what order should we do this?
Update button and accordion with correct tokens (#1826 and #1827) @BarsnesRemove inverted tokens that should not exist anymore (see list below) (In a separate branch) @mrosvik @FebakkeRename dark tokens to strong (In a separate branch) @mrosvik @Febakke (#1834)3.1Update CSS to use the new strong tokens @BarsnesCreate success, warning, danger, accent and neutral(grey) scale. How many tokens should we include to cover our needs? @Febakke @Thuneer The solid colors will not be linear, will reference to brand colors. Use Digdir, Mattilsynet, Brreg, Arbeidstilsynet as test cases.4.3The new color system should include everything in the same set. Example: "Success" should include background, surface, border, text on the same level.4.1Test token structureRenameactioncolor toaccent.Renamefirst,second,thirdtobrand1,brand2,brand3accentandneutralcolor. ~~Move base colors into two new sets "Light" and "Dark" in opposite directions. @mrosvik @Febakke (In a separate branch)4.1Test with flipping or if we need specific colors for Light and Dark. @mrosvik @Febakke4.2 Create test frames i Figma for dark and light modes with different component combinations. @Thuneer 4.3 Update the script that generates CSS @Barsnes @mimarzHow we should handle naming that includes "dark"
Following tokens with "dark" will be renamed:
surface-neutral-dark-->surface-neutral-strongsurface-neutral-dark-hover-->surface-neutral-strong-hoverborder-action-dark-->border-action-strongborder-action-dark-hover-->border-action-strong-hoversurface-first/second/third-light-->surface-first/second/third-subtlesurface-first/second/third-light-hover-->surface-first/second/third-subtle-hoversurface-first/second/third-light-active-->surface-first/second/third-subtle-activesurface-first/second/third-dark-->surface-first/second/third-strongHow we should handle naming that includes "inverted"
Following inverted color tokens will be kept:
surface-neutral-inverted(used in tooltip)text-on_inverted(used in tooltip)Following inverted colors will be deleted as they are not in use, and will be replaced by dark-mode.
surface-on_invertedsurface-on_inverted-hoversurface-on_inverted-activesurface-on_inverted-no_fillsurface-on_inverted-no_fill-hoversurface-on_inverted-no_fill-activeFollowing inverted colors will be deleted as it is only in use to solve a Figma issue (white border between accordion items)
border-on_inverted-default