Add color fallbacks for contrast and base slugs

[richtabor]

What problem does this address?

Once WordPress 6.2 lands, all core patterns will be loading directly from the WordPress Patterns directory. Themes can also load patterns from the directory using theme.json.

This is nice, but there's one big downside: Patterns loaded from the Patterns directory are limited to using the default color palette included in WordPress core — or hard-coded color values.

A closer look

Take a look at these screenshots, using a core pattern loaded within Twenty Twenty Three in multiple variations. This pattern uses hard-coded color values (the dark green and pale yellow). It looks nice as a standalone pattern, but does not fit stylistically within any particular theme's design language:

Hard-coding colors is generally fine for patterns, although we should lean more towards a design system that looks ace with any active block theme for core featured patterns.

As-is, the potential scope of a pattern is quite limited. For example, theme authors are unlikely to include a pattern from the directory in a theme - if it doesn't look right out of the box. The current solution is to publish patterns that lack color (less variety/originality) or to build patterns into a theme with their own colors (less usage across themes/designed for a specific theme).

But with just one adaptation to how core uses default color slugs, we can start moving towards a more theme-agnostic pattern library that feels closer to a theme's intended design language.

Proposal: Fallback colors

• Add color fallback CSS properties for base and contrast to --wp--preset--color--black and --wp--preset--color--white respectively.

• Add support for using standardized base and contrast color slugs in the Pattern Directory, so that patterns can start to better leverage a theme's color palette.

Why

1. Themes that use the recommended base and contrast color slugs will see patterns from the Patterns Directory that fit in better with the intended design language of the theme.

2. Theme authors can upload patterns to the directory, and re-use them across block themes via theme.json (and they still look as if they were built for the theme).

3. Themes that don't use the recommended base and contrast will render patterns built in this fashion with black and white fallback colors.

4. Patterns can count on base and contrast color values to have proper color contrast (as the theme has defined them).

Visuals

Here's the same pattern/same theme from above, but now the pattern is using contrast and base color values. Instead of hard-coding in custom color values, the colors are referenced from the theme — making the patterns feel like they belong in the theme.

These fallbacks could work like this, where if there is base/contrast those are used — and if not, use white/black:

.has-base-background-color {
    background-color: var(--wp--preset--color--base, var(--wp--preset--color--white));
}
.has-contrast-background-color {
    background-color: var(--wp--preset--color--contrast, var(--wp--preset--color--black));
}

Thoughts? @WordPress/block-themers @WordPress/gutenberg-design

[ndiego]

I really like this approach, and it will improve the usability of the Pattern Directory, especially for theme creators who want to leverage the Pattern Director for storing patterns. Patterns should be able to adapt to the theme being used. Of course, pattern creators could still use hardcoded color values, but this allows for an alternative approach.

[MaggieCabrera]

Yesss, please. I think several instances of this same conversation have occurred all over the last two years, and today the problem is as persistent as it ever was. I think this is a great idea and it's simple to implement to any existing theme. Maybe we could consider if we want or not to show these two colors in the palette shown on the sidebar, since, semantically they may not fit the rest of the palette for every single theme. Besides that I can only see benefits from having something like this.

[tts-jessicakafor]

I know of a jquery plugin that does similar to this https://briangonzalez.github.io/jquery.adaptive-backgrounds.js/

[richtabor]

Maybe we could consider if we want or not to show these two colors in the palette shown on the sidebar, since, semantically they may not fit the rest of the palette for every single theme.

I would think that if the theme does not support base and contrast, then they'd fall back to core's black and white presets — so no need to add colors to palettes.

And if a theme does want to migrate existing colors (say background and foreground slugs) to use the new base and contrast values, it could be done via a CSS fallback, like this:

.has-background-background-color  {
    background-color: var(--wp--preset--color--base, var(--wp--preset--color--background));
}
.has-background-text-color  {
   color: var(--wp--preset--color--base, var(--wp--preset--color--background));
}
.has-foreground-background-color  {
    background-color: var(--wp--preset--color--contrast, var(--wp--preset--color--foreground));
}
.has-foreground-text-color  {
   color: var(--wp--preset--color--contrast, var(--wp--preset--color--foreground));
}

[mrwweb]

This is a very real problem and so I'm strongly in favor of finding a way to support more standardized colors. Some previous discussions on these subjects happened on #29568, #38998, and #39372.

One thing I'd hope is that whatever change happens makes sure to take into account contexts beyond Patterns. To use a large popular plugin as an example, The Events Calendar offers an "accent color" option in the Customizer. I'd hope that any standardization would offer an obvious color token that The Events Calendar could use in their styles to automatically match any theme.

I'd love to eventually see some standards beyond just a few colors, but I think that starting with a few sensible ones makes sense if that can actually make it into an upcoming release. So background, foreground, and accent/contrast seems like good place to start.

[SaxonF]

The modular nature of block themes is really exciting and has the potential to modernise WordPress and bring in an audience that is more systems orientated. Mixing and matching colours, fonts, patterns etc sounds (and is) fun! So I naturally agree with the proposal here, I just wonder whether more thought needs to put into whether base and contrast (and their mapping to background/foreground) are the right approaches to adopt before promoting in the directory.

The challenge is in creating a system that is both predictable (e.g. enough contrast) and scalable. base and contrast are predictable but aren't that scalable (e.g. there is only so much you can do with two colours). I think we should be looking further into the idea of generating predictable colour scales that pattern authors know they can use in different ways.

This is an example of a programmatic approach that takes a single colour value and outputs multiple scales keeping perceived lightness constant. With something like this a pattern author could reference theme-1-0 knowing that it would be accessible against theme-1-900. This could go on theme-2, theme-3 etc with fallbacks to theme-1.

Add color fallback CSS properties for base and contrast to --wp--preset--color--black and --wp--preset--color--white respectively.

It's likely I haven't fully wrapped my head around fallback's but should the pattern just fallback to using the theme's element styling? (background, heading, text, link, button).

I know there is a lot of history behind the colour conversation as @mrwweb linked to, so apologies if we have come to some sort of conclusion there. If so, you can ignore my feedback here :D Either way, I'm excited about the potential of the pattern directory!

[richtabor]

I just wonder whether more thought needs to put into whether base and contrast (and their mapping to background/foreground) are the right approaches to adopt before promoting in the directory.

I think eventually we should just extrapolate the theme's background and text colors via theme.json, and set those programmatically as base and contrast, but in the meantime promoting a consistent convention would help.

This is an example of a programmatic approach that takes a single colour value and outputs multiple scales keeping perceived lightness constant.

I like this approach, particularly for UI work — although I don't know how common a site's color palettes would be on a scale, rather than a body background/text and multiple variable accent colors. It would be interesting to explore how we could do this, like we have spacingPresets (where core maps out the spacing values from the inputs), but I don't see as quite the same issue here, more of a workflow tool for designers wanting that much flexibility.

It's likely I haven't fully wrapped my head around fallback's but should the pattern just fallback to using the theme's element styling? (background, heading, text, link, button).

Yes, if a base/contrast value was not present, we could alternatively fall back to the theme's elements — although the patterns would lack coloring in those cases. Maybe that's fine?

[richtabor]

Related to #49279 in part. Using refs would be a better solution than relying on a theme's color slugs.

[richtabor]

Related to #49279 in part. Using refs would be a better solution than relying on a theme's color slugs.

I actually think having ref colors assignable in block attributes would be a much better solution. Closing this one.