Implicit Text, Hover, Focus Colors as Part of Color Palette

[mrwweb]

What problem does this address?

The thing that will keep me from adopting theme.json for my color palette CSS is that I prefer to automatically set text color when a user sets a background color that has poor contrast. e.g.:

.has-black-background-color {
   background-color: #000;
   color: #fff;
}

Current Experience:

Better experience!

This is a great user experience. (In fact, a client yesterday mentioned how much they loved it during their first training ever with the block editor, literally saying, "It just works!"

Without automatically setting a sensible text color, the user must make a second click for many (most?) color changes (background and text color) and also remember the consistent background-foreground combinations they use throughout the site.

Further, by increasing the number of blocks with both a background and foreground color classes, it increases the chances of bad results following a theme change that might use the same color names like primary, secondary, accent, etc. but have different contrasting colors.

What is your proposed solution?

Extend theme.json's color palettes to include an optional implicit foreground color for each color, so that background-color styles include a color CSS property as well.

Due to the point about theme changes, I wouldn't want to see this implemented as automatically setting the foreground color, because that is an independent action on top of the better default I'm proposing.

Taking this same thought process further, being able to define hover and focus styles for colors when applied to buttons and links would be even better!

[CandaceJohnsonDesigns]

I agree with what you are saying. I love the idea of presets, but setting a default for the text inside "palette" might make sense, but hover and focus can be used in a variety of ways and may be impacted by block style. Hover color could be applied to border-color, background, text, etc and the block with a background color selected may not even need or want hover effects.

Text Color Default

Theme.json

"palette": {
    {
        "slug": "white",
        "color": "#FFF",
        "name": "White",
        "default": {
            "text": "darkGray"
        }
    },
    ...
}

Implementation: Develop a hook into the block color support and set the default text color if block support allows. Block supports already allow default attribute values for color. This would also allow for cascading and overriding in block settings in theme.json.

This would set the initial value and automatically apply .has-{color-slug}-color to the block. Then the user can override that default by selecting a new text color. I think this is a cleaner approach then adding color to the background-color class.

Hover/Focus Defaults

If hover/focus colors were included as a default setting, it would need to be included in block settings for those with "hover" support. It would be great if selecting certain block styles activated supports for different hover settings. For example, a button block would be a logical choice with hover color support, but hover color support would have nested support based on the style selected.

A theme could register an "Outline" button style and add nested hover support for background-color (think Material.io imitation hover "overlay" effect) or border-color. It would depend on the theme design for that particular style. This would require big changes to implement though. NOTE: Hover support does not currently exist nor does registering block styles with varying block supports. Block styles only add a style class at this time.

[carolinan]

This was a big pain point when developing Twenty Twenty-One.
It is important that the users choice is still respected, even if the theme designer would disagree with their choice....

Perhaps there should a palette type called "color pairs"?

[mrwweb]

@carolinan I'd love to learn more about that. Are there specific tickets that would be helpful to review for understanding that history?

In my experience, so long as the background color classes are listed first and have the same or lower specificity as the text color classes, they don't interfere with user preferences. Handling all possible nesting scenarios does get more complicated but feels like it's probably still solvable.

Higher specificity via source order

.has-black-background-color {
    background-color: black;
    color: white;
}
.has-white-background-color {
    background-color: white;
    color: black;
}
.has-black-color {
    color: black;
}
.has-white-color {
    color: white;
}

Higher specificity via selector

.has-black-background-color {
    background-color: black;
    color: white;
}
:root .has-black-color {
    color: black;
}
.has-white-background-color {
    background-color: white;
    color: black;
}
:root .has-white-color {
    color: white;
}

The "color pairs:" idea would definitely be an improvement over the current state, though my concern would remain about added pain when switching themes.

[carolinan]

In Twenty Twenty-One, the button is inverted on hover; the filled style is the hovered style for the outlined, and vice versa.
The default button color changes depending on the background.
By default, the button background is dark grey. If a button is placed in a group block with a dark grey background, the default button background is the mint green...

And then all that was reverted in dark mode...
https://core.trac.wordpress.org/ticket/51927

[mrwweb]

Thinking about this more the other day, an alternative might be a dynamically calculated class for .has-dark-background or .has-light-background that is calculated based on the selected background color. This would fit in nicely with the existing .has-background class.

That way a theme could add just two new rulesets and have pretty darn good defaults:

.has-dark-background {
    color: white;
}
.has-light-background {
   color: black;
}

[overclokk]

If you use CSS Custom properties for declaring palette color values in theme.json becomes much easier to replace a color.

This is an example simplified withouth all the rest of the css, this should work (on my machine), only to get the idea:

.wp-block-button__link {
	color: var(--wp--custom--button--text);
}

.has-base-background-color {
	background-color: var(--wp--preset--color--base) !important;
}

.wp-block-button__link.has-base-background-color {
	--wp--custom--button--text: [my-custom-value-here]
}

<div class="wp-block-button">
	<a class="wp-block-button__link has-base-background-color has-background">Button</a>
</div>

You can also generate this from SASS and add hover support.

Adding contrast to more elements could stretch the css.

[eric-michel]

I posted a similar suggestion and @cbirdsong kindly pointed me to this one. I've closed my post in favor of this one.

@mrwweb

Thinking about this more the other day, an alternative might be a dynamically calculated class for .has-dark-background or .has-light-background that is calculated based on the selected background color. This would fit in nicely with the existing .has-background class.

That way a theme could add just two new rulesets and have pretty darn good defaults:

.has-dark-background {
   color: white;
}
.has-light-background {
  color: black;
}

This is exactly where I was going with my suggestion. Gutenberg already has a way to assess lightness or darkness in the editor (although it could be improved to better understand gradients). The Cover block is automatically given an .is-light class when the background color is light, and its foreground color is adjusted appropriately. However, no other block currently takes advantage of this feature.

If a simple .has-dark-background or .has-light-background is added to any element with a background selected, the theme creator can simply add the CSS you noted above, or the appropriate options could be set in theme.json and the above CSS could be generated automatically.

Because that CSS is quite general, those foreground colors can be easily overridden by the user by selecting something different from the color palette if desired, addressing @carolinan's point:

It is important that the users choice is still respected, even if the theme designer would disagree with their choice....

This method gives content creators the same amount of control they have now (they can still pick any text color from the color palette that they would like), but provides sensible defaults that better meet accessibility standards. And it does so with a very tiny amount of CSS.

[mateuswetah]

Would love to see this .has-dark-background solution.

I just noticed that in the editor side there is a .is-dark-theme class being applied to the cover block when the background is dark, but for some reason it does not show up in the theme side :(