Design system - Colour scales

[SaxonF]

Part of #53322

What problem does this address?

The current Gutenberg colour system has been great for the editor, however we are starting to see the limitations while designing for a dark surface (e.g. site editor). If we want to lean heavily into personalization, support themes including dark, and offer a contrast preference (empowering users to achieve AAA conformance), then we will need to extend the system and take a more programmatic approach.

One of the biggest gaps in our current system is a limited bottom end of the scale. e.g. for component backgrounds, states etc

What is your proposed solution?

We can learn a lot from other systems out there, one of which is Radix colors. One additional piece of complexity is that we'd ideally want to programmatically generate themes based on single colour values. The benefit of a scale like Radix is that "each step was designed for at least one specific use case." This means that you have contrast guidelines built in ("Step 11 is designed for 400 weight text in any size, and guaranteed to work well on a step 3 background. Each test should pass 4.5:1 contrast ratio.")

The good news is that we already have an experimental theme provider in our components package and tools to generate scales based on a single value.

• Design a new colour scale
• Programatically generate these scales via theme provider
• Update primitives to make use of theme
• Update environments to use theme provider

[Ren2049]

Are there plans to integrate Superpal into WordPress? Would be great to have something like this available not only for plugin devs but for theme design and something "AI" theme setup wizards can tap into.

An alternative could be a large enough database of colors/scales.

I'm kind of a color nerd and during my own research into colors I've landed on 30 hues within an oklab circle (12 steps apart), 12 contrast steps per hue and 6 different saturations (5%, 20% 40%, 60%, 80%, 100%), 2160 "colors" in total.

This covers all design intents I can think of. When somebody pastes a RGB Hex color it could be read out as hsl, mapped to one of the 30 hues and 6 saturations, and it work equally well because the circle is dense enough with 30 hues and deep enough with the 6 saturations.

Here is the 30 hue okhsv/okhsl circle with each color at its natural peak chroma. The okxxx space also enables a nice even division between cool and warm colors.

The visual difference of the cyans manifests at different contrasts, not so much at peak chroma in the circle.

Here are the oklch scales in Leonardocolor.io, broken up into 3 links because it would otherwise too big for leonardo to load:

Leonardo: Yellow to Magenta

Leonardo: Magenta to Cyan

Leonardo: Cyan to Yellow

The scales are at 100% saturation, but the other saturations can be easily generated with the theme settings next to the blue share button, which also provides an option to export the color values.

The contrast/lightness steps are what I use lately, but it's also easy to adjust.

[jameskoster]

Inspired by Radix I tried a couple of scales (light and dark mode) that are purely gray and generated using https://hihayk.github.io/scale/.

This is very much an initial exploration, not a proposal.

Step	Light mode	Dark mode	Purpose
0	#fffffff	Alias: 1	A mutable alias that enables the use of a pure white background for the light theme while not translating to a pure black background on the dark theme.
1	#fcfcfc	#161616	Surface backgrounds. Generic examples being the main background, cards, menus, page headers, and so on.
2	#f8f8f8	#1c1c1c
3	#f3f3f3	#232323	Secondary button background. Step 4 = hover, step 5= active.
4	#ededed	#282828
5	#e8e8e8	#2e2e2e
6	#e2e2e2	#343434	Subtle borders, typically this will be applied to non-interactive elements like cards, panels, and separators.
7	#dbdbdb	#3e3e3e	Interactive element borders. Step 8 is for the hover state of those elements.
8	#c7c7c7	`#505050`
9	#8f8f8f	#707070	Solid background elements like buttons (though the accent color might be a better candidate). When higher contrast is required these steps can be conditionally used in place of 7 and 8 for borders.
10	#858585	#7e7e7e
11	#6f6f6f	#a0a0a0	Text. Step 11 will achieve 4.5:1 contrast against background colors 1, 2, and 3. White text can be used atop step 9 in either theme and meet contrast requirements for large text (weight >= 600, size >= 19px).
12	#171717	#ededed

Here's an example of the UI elements this scale could produce:

Note: Details like spacing, radius, shadow, and type are naturally related, but not directly relevant to this issue—the focus of which is purely color. Those elements should be explored in separate issues.

Aliases

In addition to steps 0, 9, and 10, as described above, aliases may also be needed for things like:

• Saturated shadows (gray in light mode versus pure black in dark mode).
• Overlays (a lighter background treatment might be desirable in light mode than dark mode).
• Any element that has a transparent pure white background in light mode and a transparent pure black background in dark mode (tooltips are a candidate).

Such needs will become apparent as we investigate other elements of the design system such as the full suite of primitive components, elevation, and so on.

As mentioned above this is just an initial exploration. I'd like to try a version using Superpal, but given the scales it generates seem to be very linear I wonder if it might be tricky to apply semantic purpose to each value in a way that works equally well in light and dark modes?

I also have a question about how to utilise the accent color – should it be applied sparingly to specific elements like primary buttons like the example here, or should the entire scale be derived from it so that the interface is be 'tinted' instead of purely gray?

[jameskoster]

Here's a riff on the above using Superpal. All colors are from the 'Gray' scale which is derived from the 'blueberry' hex color #3858E9 and so have a subtle blue tint. It works better than I expected!

For reference:

• 0 – Pure white background for light mode.

• 50 – Alternative surface background. Primary button, and active toggles foreground.

• 100 – Secondary button background. Subtle borders.

• 200 – Secondary + Tertiary button hover state. Interactive element borders (in low contrast mode).

• 300 – Secondary + Tertiary button active state. Hovered interactive elements (in low contrast mode).

• 400 – Focus rings*

• 500 – lowest contrast text with AA compatibility (e.g. input placeholders). Interactive borders (in high contrast mode).

• 600 – lower contrast text (e.g. help text). Interactive borders hovered (in high contrast mode).

• 700 – Regular contrast text.

• 800 – Highest contrast text. Primary button background.

• 900 – Primary button hovered. Active toggle background. Range handle.*

• – For the default admin theme we might want to use colors from a different palette here to avoid the gray monotony.

Superpal config

[SaxonF]

@jameskoster and I have spent some time playing around with this in code the results of which you can see below.

color-change.mp4

The PR here goes in to more detail so I'd recommend reading if you're interested. Importantly, the work in that PR lays the foundation for better management of admin tokens in general including spacing, fonts, border radius, shadows etc.

[oandregal]

For the record, I've grouped together issues related to "theming" in the dataviews component issue, so they are visible #55083 This one is larger than DataViews but it also impacts it.