Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map color presets like spacing presets for improved theme interoperability #53996

Open
richtabor opened this issue Aug 28, 2023 · 8 comments
Open
Labels
[Feature] Colors Color management [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Enhancement A suggestion for improvement.

Comments

@richtabor
Copy link
Member

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.

@richtabor richtabor added [Type] Enhancement A suggestion for improvement. [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Feature] Colors Color management labels Aug 28, 2023
@cbirdsong
Copy link

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

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
Copy link
Member Author

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
Copy link
Contributor

jasmussen commented Aug 29, 2023

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
Copy link

Ren2049 commented Aug 29, 2023

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?

tokens

@richtabor
Copy link
Member Author

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
Copy link
Contributor

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

@jarekmorawski
Copy link

jarekmorawski commented Mar 20, 2024

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.

image

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Colors Color management [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants