Map color presets like spacing presets for improved theme interoperability

[richtabor]

Thought of a potential avenue for improving how colors map across themes/variations.

The way I proposed colors for Twenty Twenty Four (WordPress/twentytwentyfour#106) is to provide variants of base, contrast and accent. These represented as base-2, contrast-2, accent, accent-2, accent-3, etc.

What if we treated these values like we do the spacing scale?

If there is no accent-3 registered, it will resolve to accent-2 instead — and if there is no accent-2, fallback to accent-1.

The same would follow for base and contrast colors.

This way themes (and style variations) would be much more interoperable — instead of today, where if you use a color preset that does not map to a newly applied theme.json set, the color applied is missing completely. With this proposal, that would be the last-case fallback — after first checking for related alternatives.

[cbirdsong]

I think something like this has been proposed a few different times, most notably in:

• Explore options for standardizing and extending theme.json design tokens for colors #39372

I would love to see this idea get more traction. Standardizing these could actually make the pattern directory useful for themes with strict design requirements.

[richtabor]

I don’t think the terms matter that much.

If the -1, -2, -3 fallback mechanism was in place (for any color preset potentially) we don’t have to be so prescriptive, as most of those ideas lean that direction.

[jasmussen]

I don’t think the terms matter that much.

The terms have been what's always made me stumble here, i.e. as soon as we canonize a term we're stuck with it, and it's been very hard to get people to agree on which terms to then go with. So to be sure I'm getting this right, you're suggesting that, if a pattern leverages [colorslug]-3, and you switch themes, it will first look for [colorslug]-3, then [colorslug]-2, then [colorslug]-1 to see which is available. What would happen if [colorslug] isn't available at all in the new theme?

Edit: to be clear, [colorslug] not being available in the new theme would still be a case we had to handle even if we all decided to canonize a specific term, like accent.

[Ren2049]

Why not stick to global tokens (color-100, 200, 300.. or "colorless" neutral-100, 200.. / brand-100, 200..)? Or maybe a stacked token system with global tokens (relating to contrasts) as the fall-back option?

[richtabor]

So to be sure I'm getting this right, you're suggesting that, if a pattern leverages [colorslug]-3, and you switch themes, it will first look for [colorslug]-3, then [colorslug]-2, then [colorslug]-1 to see which is available.

Yes, like how spacing presets work basically.

What would happen if [colorslug] isn't available at all in the new theme?

If a theme is using more "custom" color slugs, I don't know that we could map them effectively without some heavy lifting.

[jasmussen]

To me that seems like a valuable small step forward, that doesn't require us to canonize any terms 👍 👍

[jarekmorawski]

I really enjoyed reading through this conversation. It's a big problem to solve, but once we do that, swapping themes will become much easier. Have we made any progress recently? What needs to happen to push this work forward?

I ran into this issue while designing blocks and patterns that come with more than a few color settings. For instance, I have a chip element that has with 6 settings: background, text, border, dismiss button, and dismiss button background. Ideally, all of them would sync with Global Styles out of the box, but it's difficult to specify the target colors because they're not standardized across themes.

A set color swatch relative to its position in the GS palette, like color-3 or color-4, can be black in one theme and vibrant orange in another, which will make the chip illegible on most backgrounds.

On a related note, would it make sense to include color variations, too? Or at least make it possible to change the color's opacity without detaching it from the palette. In the chip example, the text, dismiss button, and the border would all use color-1, but the border would have 50% opacity to make it subtler.

[hanneslsm]

Small, but relevant:

and if there is no accent-2, fallback to accent-1

… and if there is no accent-1 (as there isn't in TT4), fallback to accent