Define preset color array and naming convention for uniform colors across themes

[mor10]

Is your feature request related to a problem? Please describe.
Themes can define custom colors with custom names (eg "Goblin Green"). If an author uses a custom color as a background in a post, and then switches to another theme which does not have this color defined, a fallback takes place and the color disappears.

Describe the solution you'd like
There should be a defined color array and naming convention established which enables theme developers to use the same names for colors and coordinate these colors with their themes. That way when an author uses a color customized for one theme and switches to another theme, the color changes with the theme and the expected behavior is preserved.

Theme developers should be encouraged to always define these colors and use this naming convention, and only use custom colors and color names in situations where they are doing something out of the ordinary.

The naming convention could have a protected prefix like "theme",

Some colors should always be defined:
theme-primary = key / primary color
theme-secondary = secondary color
theme-background = color intended as primary background (contrasts to theme-foreground)
theme-foreground = color intended as primary foreground (contrasts to theme-background)

Additionally some standard color names should be protected and definitions encouraged:
theme-red
theme-orange
theme-yellow
theme-green
theme-blue
theme-indigo
theme-violet
theme-black
theme-grey-dark
theme-grey-light
theme-white

For all these color definitions core should provide fallbacks.

Employing this kind of naming convention (or something like it) will ensure a seamless transition between themes while allowing theme developers full control over exactly what colors are in use and where.

[philliproth]

I thought about this aswell and thought the array of colours available in Gutenberg should be stored and managed in the Customizer somehow. Wouldn't this make more sense from a user perspective? To have the layouty-fonty-colory-options all in one place?

[addzycullen]

I feel like this is a much needed feature, but having heard and read rumours about future plans for Gutenberg to take over Wordpress completely, starting with the customiser(after the editor of course) then I fear we may not see anything like this until then.

I've wrote a plugin that does something like this for a gutenberg theme I've been working on, editor settings such as the editor color palette and editor-font-sizes etc are all controlled from the customiser and stored in the options table. obviously this isn't a help to anybody else other than ourselves as it's not built into Gutenberg now, but it'll allow us internally to switch any gutenberg compatible themes out that we've built with relative ease without reinventing the wheel each time.

TLDR; this is a great feature request and should be explored further!

[mor10]

Moving this forward:

Having pre-defined color classes as proposed here will open the door to multiple enhancements for theme developers:

• Themes can declare specific colors that fit the current setup so the colors change with the theme.
• Themes can declare multiple color schemes and have the already applied colors change consistently.
• The naming convention can be extended to plugins (ie myplugin-primary, myplugin-secondary etc).

A scenario to explain how this could work in the dashboard

Maiken writes a post and wants to highlight a specific paragraph within a post. They go to the block property panel and select font and background color from the "Theme Colors" section.

Some time later, they decide to change the theme or the color scheme of the theme. Because they used a theme color, the colors previously applied to the paragraph automatically update to the new theme / color scheme.

What happens if we don't do this

The risk of not creating this convention is every theme developer will use their own naming conventions for the color classes and applied colors will either disappear or act in unexpected ways when a site owner changes themes.

The end-user has a reasonable expectation that a color applied to an element will stay. Clearly identifying and separating theme-specific colors, custom theme colors, and default colors ensures a) users can understand what they are doing when adding a color to an element and b) developers are cognizant of the long-term implications of adding custom theme colors.

[chrisvanpatten]

I think this is an interesting and sensible idea, as long as it's implemented in a way where custom/enterprise developers who don't need to support theme interop can continue to define fully custom palettes!

[mor10]

@chrisvanpatten That's one of the purposes of this proposal: To clearly delineate what defined colors are created for interop (prefixed theme-), what defined colors are custom for this specific theme (prefixed [themename]- or custom- or something similar), and what colors are default. It provides full freedom for developers while putting a system in place for robust interop between themes.

[mor10]

Looping back to this. We are proposing a naming convention for this in WP Rig:

– Theme-specific colors which are likely to be refined across many themes should have slugs following the theme-[color] naming convention. So theme-red, theme-blue etc.
– All themes should have a theme-primary and theme-secondary color defined (can be any color)
– Any custom colors unlikely to be re-used should have slugs following the custom-[color] naming convention.

Example: https://github.com/wprig/wprig/blob/v2.0/inc/Editor/Component.php#L55-L114

This ensures a user who sets the background of a paragraph block to theme-red will still see a red background if they switch to a different theme.

[mapk]

I like the concept behind this, @mor10. Theme switching can cause so many problems. This would help alleviate that color switching mess.

My suggestion here is to drop the theme- prefix for something else like color-. I feel that using color would be more explicit. But I could be missing something here.

color-primary
color-secondary
color-blue
color-red
etc...

I'd like to get some other eyes on this as well. @davidakennedy or @laurelfulford any thoughts?

[mor10]

I proposed theme- because it explicitly states the color is defined by the theme, and it avoids conflicts with other styles. A class named color- could pop up in another context quite easily. The theme- naming convention could easily be expanded to also include plugin- and even [plugin-name]- etc.

[0aveRyan]

I like this idea in concept, but I have a few concerns.

I'm not sure I'm fully-sold on the Theme switching benefit @mor10 @mapk... One theme may have a dark maroon registered as color-red, while another may have a pink-ish red registered. Upon switch, this could cause chaos if color-red was used as background or text color. I'd worry about codifying too many colors to address this -- or too few.

Additionally, one shortcoming with current implementation is that all colors from a palette are presented.

I would love to eventually see a mechanism for developers to register color relationships, such that selecting a new background color would automatically narrow the text color options to appropriate matches (i.e. user selects dark Maroon background and dark/conflicting hues are removed from text color options). A half-baked, more automated iteration mentioned here. But again, these relationships wouldn't necessarily translate well in-between Themes.

[mor10]

@0aveRyan the current situation is that someone applies a color to a block, then switched theme, and most likely the color goes away entirely, which classifies as unexpected behavior and will be perceived as something being broken. By standardizing key names like "primary" and "secondary" we can do some pretty interesting things. Example: a theme with different color options, say "light", "dark", and "purple" can have separate colors defined for primary and secondary, and when the user switches between those options, blocks with primary and secondary colors automatically switch to match. This is what the user would expect.

[0aveRyan]

@mor10 I appreciate that potential benefit of standardized slugs, color schemes and that the current situation can cause users to perceive something as broken, but that response doesn't address the concerns I raised. I'm onboard with color-primary, color-secondary, color-background and color-foreground -- it's codifying primary and secondary colors I worry will create as many problems as it aims to solve.

Whether a color disappears entirely or morphs from Dark Maroon to Light Pink, those are both unexpected behaviors -- Why did my reds all turn into pink -- that's not red? Why did my evergreen all turn into lime? Sure, a user may initiate Theme switch and expect changes in color, but both disappearing and inverting will cause equally poor visual changes and the perception of a site breaking.

Are there benefits beyond switching themes?
Can you present a complete list of colors you'd hope to codify?

[mor10]

@0aveRyan What you're describing is less a problem of my proposal than a problem of how these colors are presented to the end-user at present.

There needs to be a clear distinction between functional colors and presentational colors. If you use the Twenty Nineteen theme for example, you get a reduced color palette to fit with the overall color scheme of the theme. These colors are highly opinionated and designed to be consistent. Coloring a button with the pre-defined blue is done by the user to make that button stand out. It is thus a functional color rather than a presentational one: The user is not making it pretty but making it stand out. If the color scheme is split as I proposed earlier into Theme colors (functional) and other colors (presentational), and this is communicated in a more understandable way, the swapping behavior will be expected and appreciated.

To flip the example on its head: Right now, if you apply the Twenty Nineteen blue to a button to highlight it, and swap to a different theme, the highlight goes away. That is not what the user wants nor intends. If on the other hand the user knew through the labeling that the color they applied was the primary key color, they would expect its function to carry over to another theme and follow the color palette in the new theme.

[colorful-tones]

There are only two hard things in Computer Science: cache invalidation and naming things.

• Phil Karlton

I.e. naming variables is hard. This seems to be compounded when it comes to discussing colors.

I think codifying the names is a great solution, and I quite like @mor10 proposed naming conventions: theme-, custom-.

I would only add that they likely should be a bit more explicit, and all prefixed with color-:

color-theme-primary
color-theme-secondary
color-custom-dusty-sunset
color-red
color-blue

@0aveRyan

Are there benefits beyond switching themes?

The only thing I might add here is that it is possible for plugins to register colors as well. Therefore, this would help plugin authors have a standard approach.

Can you present a complete list of colors you'd hope to codify?

I like Morten's original list and would round it out with the following:

color-theme-primary
color-theme-secondary

color-theme-background
color-theme-foreground

color-black
color-white
color-silver
color-gray

color-marooon
color-red
color-purple
color-fuchsia
color-green
color-lime
color-olive
color-yellow
color-navy
color-blue
color-teal
color-aqua

Mostly falling in line with HTML 4.01 (1999) spec.

Also, just wanted to note that this plugin exists and is an intriguing solution: https://en-ca.wordpress.org/plugins/kt-tinymce-color-grid/ , which kind of reinforces the need for a consistent core mechanism.

[mtias]

Consolidating discussion in #29568 which has become more active.