Standardize theme editor color names

[justintadlock]

WP Rig is creating a standardized theme editor color palette naming scheme. I think we should follow suit. See: https://github.com/wprig/wprig/blob/v2.0/inc/Editor/Component.php#L47-L114

The purpose of this is to create a naming scheme that has forward-compatibility between themes. It wouldn't address all compat problems, but it would help eliminate many of them and allow users to continue seeing their color choices reflected when switching themes if enough theme authors followed suit.

Primary and secondary color:

• theme-primary
• theme-secondary

Setting basic colors:

• theme-black
• theme-white
• theme-blue
• theme-green
• theme-yellow
• theme-gray
• theme-red

Custom colors:

• custom-colorname

CC: @mor10 in case he has any additional info/ideas related to this not covered.

[mor10]

Related Gutenberg ticket: WordPress/gutenberg#7553

[justintadlock]

After some time with this in a real-world project, I'm really not seeing it as solving many problems.

One theme's blue color may be dark where another theme's blue color may be light, for example. That may very well cause more problems.

I've taken two approaches to handling this:

Default background and text colors:

I've assigned a default background for the .has-background class and a default text color to the .has-text-color class.

This way, even if it's not the user's chosen colors, the paragraph (or whatever block) is still "highlighted" in some way. It's not perfect, but it should cover a lot of ground.

Color spectrum:

I've also followed Tailwind's color naming system to create 10 colors with 7 shades + black and white. I don't necessarily put all 72 of those colors in the editor palette. I just use the ones that make sense for the project.

red-lightest
red-lighter
red-light
red
red-dark
red-darker
red-darkest

On the theme- and custom- prefixes

I don't agree that we need the theme-{$color} and custom-{$color} naming scheme.

First, these are theme colors by default. That's why they're added via the add_theme_support() call. Prefixing for themes here doesn't help us much. All colors added should be under the theme's "namespace" (for lack of a better phrase).

It's only when something like a plugin decides to do something different and add in colors does prefixing need to happen. And, the standard for prefixing with something like plugin- or {$pluginname}- should fall to plugin developers.

My second gripe with this is the prefix adds more weight to final CSS files. .has-blue-background-color is lighter weight than .has-theme-blue-background-color.

I already wish core would've simply used .bg-{$color} and .text-{$color} to shorten these a bit.

With a few definitions, this isn't a big deal. With many colors, it starts adding up. And, it adds up even more when you start having to do things with :hover, :focus, and other states.

Side note to this: I find the argument of Gzipping and minification irrelevant here. Every byte and every user matter.

[mor10]

The theme-{color} and custom-{color} prefixes were part of the larger proposal of extending the UI to clearly visualize what is going on with colors (see WordPress/gutenberg#7553 (comment)). Since there is little movement on that front, I think your arguments are valid and we should discuss a common naming convention.

As for whether the overall approach solves problems, I disagree with your conclusion. Having watched users apply custom colors to their blocks only to see them vanish mysteriously when they switch themes is a clear indication the core solution creates unexpected behavior. By establishing a naming convention around primary, secondary, key, etc colors, theme developers can create more extended color themes for things like dark/light color palettes and style variations, and enable natural transitions when users swap themes.

The problem as I see it isn't as much with the actual colors but rather that Gutenberg insists on calling them by their names rather than their function. Thus the primary and secondary monikers. A user who wants to highlight a specific block will want to use colors to do so. If the theme ships with a color called prussian-blue as the first available highlight color, there is pretty much zero chance the user will see a natural transition if they swap to a different theme. A fallback to a neutral highlight does not help, and in any case needs to be supplied by core to be consistent so it's a bit of a red herring. Long term, the ideal solution is a split between functional colors - primary, secondary, key, etc - and decoration colors. Decoration colors can fall to the wayside during a theme transition. Functional colors should not: They should follow the overall theme color palette, so if the primary color in theme A is blue and theme B is red, the theme transition should result in any element with the primary color applied wapping from blue to red. This would be expected behavior.

In my opinion.

[justintadlock]

I do want to note that I'm very much in favor of standardizing on a functional color naming system, which is the primary reason this ticket is still open.

[mor10]

Let's put our heads together and come up with a joint proposal for core!

[aristath]

If there's any kind of standardization, I think it would be important to note if the color is dark or light for accessibility reasons.
Let's say for example that I call my theme's colors theme-blue-light, theme-green-dark, theme-gray-light, theme-red-dark, and there's another theme with colors theme-purple-dark and theme-white-light.
A user then creates a block on theme A and chooses dark-red background with light-gray text.
If then they switch to theme B, chances are the text will not be readable.
However, if core detects that the colors I was using were dark background with light text, in case the selected colors are not available it can at least switch to some other dark background and light text.
It may not be perfect, but at least it will be readable and won't break anything.
Instead of dark-red background with light-gray text the new theme will show dark-purple background with white text. It sure beats white on white