Default Colors, Theme Colors, and Custom Colors

[mtias]

What is the problem?

Color handling in Gutenberg comes in two forms: colors picked from a palette and custom colors. Core provides a default color palette which can be overwritten by a theme. Colors assigned to a palette are expressed through classes. The same model applies to gradients. This is issue is not about the technical aspects of when to classes, inline styles, variables, etc, are employed but about the user expectations and theme integration.

At the moment, it’s frustrating as a user that upon switching to a theme that overwrites the default color palette you lose access to the rainbow-color set that comes with core. The core palette aims to provide quick access to distinct hues reliably. A theme palette generally aims to define a restricted set of semantic colors for branding.

The heart of the issue is the conflict that arises since colors are not always used semantically but also for individual expression. A theme might have added a color palette with just two colors — a green and a black — to define its aesthetics. Now, if a user is interacting with a pattern that contains an image with a rural landscape and the green color is picked because it matches the tone of the image, that use is not semantic in the sense the user wouldn’t expect it to change if they switch themes. Gradients are even more pronounced given there’s no sense of “primary”, “secondary”, not even distinct color names and they can be a lot more decorative (the theme Seedlet is a good example, with gradients that work more as background patterns). Assembling a gradient from scratch is also more laborious.

This distinction between semantic colors and local colors has implications for theme switching, global styles, etc. So we need to expand the handling of colors.

Another problem is tying user customization to globally used colors. Right now a custom color can only be replicated by remembering and replicating its color code. There should be an easier way to transfer a local color choice into the shared palette.

Finally we have the situation of patterns, which need to set inline colors right now to ensure they work as expected. This shouldn’t be needed if the pattern wants to use a color from the default color palette.

Proposal

Separate the core palette from the theme palette

A first step is to make the theme color palette something that works in addition to the default palette. That would allow themes to register preferred colors without necessarily overwriting the default palette. Of course, it still needs to be possible to fully disable the default palette since sites that have stricter branding guidelines might prefer to remove it entirely, the same way the custom colors interface can be disabled, but it should not be the default behaviour that a theme palette overwrites the color palette.

Treat theme colors semantically

The other part is treating theme colors as colors that should change upon a theme switch. This is obvious for the global styles context, where headings or link colors set to a theme color should change when switching themes. But it can also be extended to theme colors employed locally.

There is always going to be some uncertainty in determining what the intention is when applying a local color, but by having a more clearly defined “Theme” group we can set a better expectation than what is currently the case — if I apply a theme color rather than a color from the spectrum to a button block, it’s easier to expect it to change upon theme switching.

The approach of having theme colors more clearly presented in the UI, in addition to the default color-spectrum, will allow us to finally tackle a big part of the conundrum outlined in #7553. Theme colors (of the primary and secondary kind) will be expected to map to the same variables on the next theme while dark-red and light-blue are consistently provided by core but could still be tweaked within their hue range in a still predictable way (for example, we might update the default color palette with a "vibrant" or "muted" variant of the same color-coded names).

Extending the default palette

The default palette should be user customizable (as it is now in Global Styles), so a user can add, edit, or remove from it and sustain it through theme changes. That doesn't change. It's conceivable that the current colors in the default palette would need to be added, updated, or removed in the future. We should work with the assumption that we might add more default palettes in the future and that we should retain the current mappings indefinitely.

Bubble up local changes

Colors picked locally could automatically become part of the custom user palette so that the next time they want to pick the same color it's present there. A user should be able to remove a custom color at any time so that the custom palette doesn’t grow indefinitely if you use many custom colors locally. A tricky implementation detail is how to go from inline disposable color to a class-based one for this reuse, but this also helps address that problem by making it more obvious that adding a color (at least in certain contexts) automatically creates a class mapping for it.

Integration with patterns

By ensuring the default colors are present through their class mappings patterns can reliably work with them even in cases where they might not figure out in the UI for whatever reason. This is important to support a wide range of patterns and limit the need to resort to inline styles for effects.

[aristath]

Implementing multiple palettes as described above would go a long way and improve things both for end-users and developers.
The only thing I would like to add to the above proposal is that ideally we'd also have some sort of universal naming convention for theme-defined colors.
This way the "primary" color will most likely be named primary and not mytheme-primary-dark, sothings won't break when switching themes.

[pbking]

Reading the above I imagine:

Gutenberg by default will provide a given set of styles. "Semantic" styles. These are the agreed-upon colors that will always be provided. Themes depend on it, patterns depend on it, blocks depend on it.

--wp--preset--colors--primary is always something we can depend on. This is what you mean by "core palette".

A theme can use that variable to style blocks. "Primary goes in this color, foreground goes in that color"
A theme can set those variables. Maybe even from colors in the palette it provides.
"Primary = 'golden pond'"

A user can set that value to whatever they want. When they do change that value it sticks between themes. If they change any value of the primary, etc set that it's locked in. That's their global palette. If they reset the global styles then that palette goes to whatever the theme expressed or whatever Gutenberg defaults it to if the theme doesn't express anything.

Templates and blocks can use those variables and styles in their templating. ".has-primary-color" will always be available what you (and the user) think it is.

[mtias]

@nosolosw one of the quick steps I imagine here would be to introduce a new defaultColorPalette = true property in theme.json, which themes can disable if they don't want default colors at all.

[oandregal]

one of the quick steps I imagine here would be to introduce a new defaultColorPalette = true property in theme.json, which themes can disable if they don't want default colors at all.

Thinking on UI: what do you think would be a good first step to match that change? Do we need to create separated palettes in the UI or can we start by having a long list of colors with what we have today (sorted: first core, then theme)?

The default palette should be user customizable (as it is now in Global Styles), so a user can add, edit, or remove from it and sustain it through theme changes. That doesn't change.

So, the user can change all palettes (core, theme, user). In terms of theme.json shape/keys, everything can remain the same, we just need to change behavior (don't overwrite palettes).

What are your thoughts on themes changing the color value of the color palette? For example, does it make sense that a theme can change the core yellow's value to a different sort of yellow? I'm thinking we don't need this to start, it seems to go against the spirit of this issue. If we wanted to do this, we could offer the option to only change the values but not the slug (so the generated classes still have the same names) or the UI name (so there's an incentive that themes that change the color don't do things like changing a yellow to a purple).

We should work with the assumption that we might add more default palettes in the future and that we should retain the current mappings indefinitely.

I'm thinking that we may want to cross that bridge when we get to it? Food for thought: depending on our needs, we could do different things such as allow multiple palettes per origin (multiple palettes for core, multiple for themes, etc), allow for having colors that aren't shown in the UI but still generate classes (deprecated colors, so to speak), etc.

[mtias]

Do we need to create separated palettes in the UI or can we start by having a long list of colors with what we have today (sorted: first core, then theme)?

Yes, listing one after the other is fine for now.

For example, does it make sense that a theme can change the core yellow's value to a different sort of yellow? I'm thinking we don't need this to start, it seems to go against the spirit of this issue.

Right, this is not planned to be changeable at first through themes. In the future we might unlock the values like you describe.

I'm thinking that we may want to cross that bridge when we get to it?

Agreed :)