Expand color scale with custom steps

[Febakke]

Description

There has been multiple feedback on the need of a color used for icons. Out thought when building the color system was that text-subtle and text-default would be used. But in some cases there are a need to specificly control color for icons.

Naming

Icon is a very narrow use case. We should find a name that is more generic, but still semantic enough so that users understand what is should be used for.

Breaking changes

It must be backwards compatible, if not it would have to wait until v.2. But best case is to not do anything that breaks anything in production.

Solutions

1. Add another token to our color scales.

Simple solution, but need to be thought trough to fit with the rest of our semantic scale. It should be obvious what the color is supposed to be used for.

Adding it to the end of our scale would not break anything. (I think) But needs to implemented in theme builder, CLI and config.

Downside

• What will we do when the next request comes in? Expand again? Might get bloated and to complex over time.

2. Alias tokens in the semantic layer

Another suggestion is to add a layer in the semantic/style. This would work as a way to connect one color from the color scale to an icon token.

Downside

• You cannot create a unique color for icons. It needs to be one of the colors already in the scale
• You would have to make a main, support and neutral version of the token
• Can quickly expand with requests and get bloated

3. Add custom steps to color scale

Let the user create custom steps with unique name and color value for their use cases.

[eirikbacker]

We i Mattilsynet have experienced this need too.
Generally our users do not understand they can use -text-* colors for icons or generally "content" - stuff that should contrast the background like a chart-bar.
Therefore, we have discussed the option to change to "-content-*".

I agree icon is too specific, as we have seen both in components, and the -text-* name, that specific names can be too rigid. I think surface is a nice example of a "loose but semantic" definition. Border as well (since we can use it for strokes too).

PS: When other companies have approached us in Mattilsynet to discuss usage of Designsytemet, tokens is one of the big sell-in-points. We have then experienced that also the *-subtle name can be a bit too rigid. Sometimes, we just need "secondary" or a "variant of" color on text/content (like an icon, or a text contrast (like https://www.patentstyret.no/ uses on their headings in cards on hover)). If *-subtle was named *-tinted, this would make it more diverse; for some it might be a slightly darker shade of the same color, but for some it might just boost the hue. It would also align with -tinted from surface and background ☺️

PS2: border-strong is only used in the deprecated combobox and button[data-variant="secondary"] today. If text-default was named content-default, packages/css/src/button.css could use border: var(--ds-color-content-default) and still be semantically correct. This would remove border-strong entirely, removing 1.4 KB of CSS tokens ☺️

PS3: I understand these are "breaking changes thoughts", and though I also have expressed them before release of V1, I think we should rather do a deprecation of text- and border-strong than breaking change ☺️

[Febakke]

might be solved by #4054