Element colour sets

[SaxonF]

What problem does this address?

This is partly a follow up to this issue and colour token naming standardisation in general. Lots of discussions about this in the past . Its super important to get right as its a core requirement for creating this mix and match type experience we are looking for. e.g. sharing patterns across the community and having them fit right into your site.

A lot of the previous discussions have been around encouraging a standard way of naming colours in a non semantic way (e.g. base, contrast or theme-1, theme-2 etc) to enforce cross theme pattern compatibility. This still feels a little fragile unless you force map colours to elements like background and text. A more stable approach might be to rely on the theme's element styling, however you are then limited in terms of what colour combinations are possible (95% of patterns in directory will be white/black).

@richtabor and I started discussing the idea of colour sets for elements and how that would almost remove the need to try and enforce standard colour names in your palette. Rich has already done some really interesting exploration in this area.

What would this look like?

You can ignore the UI details in the video below but basically a theme creator could optionally provide multiple variations of colours for each element on their site. These variations are then available for groups/patterns to reference. Patterns shared in the pattern directory would only use default element styling where possible so that a themes element variations can be applied to them.

flow.mp4

Much like other global style properties, including style variations, element variations should be able to be managed via UI and theme.json which could look something like the below.

{
  "elements": {
    "button": {
      "typography": {
        "fontWeight": "700",
        "fontSize": "1.2rem"
      },
      "color": {
        "variations": {
          "light": {
            "background": "#111111",
            "text": "#fafafa"
          },
          "dark": {
            "background": "#fafafa",
            "text": "#111111"
          },
          "brand": {
            "background": "transparent",
            "text": "#111111"
          }
        }
      },
      "border": {
        "radius": "0",
        "width": "2px",
        "style": "solid"
      }
    },
    "heading": {
      "color": {
        "variations": {
          "light": {
            "background": "#111111",
            "text": "#fafafa"
          },
          "dark": {
            "background": "#fafafa",
            "text": "#111111"
          },
          "brand": {
            "background": "transparent",
            "text": "#111111"
          }
        }
      }
    }
  }
}

[jasmussen]

Color sets is close to my heart.

The main challenge here is to end up with something that feels really resilient and future proof. Perhaps the main challenge (and a key subject of #29568) is to always keep in mind: how to colors transfer across themes? How do patterns leverage colors? Specifically as far as sets go, could/should there be any DNA shared with font sets (#45271)?

Another challenge is naming colors, also discussed at length (see also #38998 and #39372), is useful to get right for any color sets. Do we call a green shade “green”? Or do we call it “accent”? What happens if you apply a particularly named color as if it’s an accent, but then change the color value later on? What if you call a color “background” but apply it to text in dark mode? Should you call colors based on intent, such as “Main”, “Muted”, “Contrast”, or other utilitarian terms? I’m genuinely unsure of a good system here. It seems likely you'll always be able to rename and edit colors, but just putting out there that a solid system out of the box will help.

On color sets, one idea that would be interesting to explore at least visually, could be the idea of inferred colors. Essentially, I'd love to be able to pick a single contentOnly locked pattern, and change one or two colors, and all inferred colors seeded from those two are updated across the whole pattern. How might that work? This is an older exploration that uses HSL to accomplish it. That might not be an ideal fit, but in that setup you'd be able to infer light, dark, muted, accent colors from a single hue provided.

Illustrator takes it much further than would ever be appropriate for the block editor, but is nevertheless a good example of how it would be fun to see color harmonies stay connected rigth up until you explicitly choose to customize one particular color:

[cbirdsong]

This is similar to the idea I was trying to describe in #39028.

I really like the idea of encouraging the creation of color/font presets like this. Editors shouldn't be making decisions about basic color choices with editing unless it's a highly art-directed area of the site. Instead, they should be choosing from consistent sets of colors that are applied to the container and can be updated without having to then go edit every piece of content on the site. That matches with the way they should think about designing for the web - set sensible defaults, then only override those when necessary.

This quickly gets into #39372 territory, but I think you could start with "light" and "dark" as the base sets of colors and then have any additional sets cascade down as child variations on those two. If you're adding a new color palette it will fundamentally be a variation on your default light or dark colors, and you should only need to pick one of those and override whatever colors need to be different instead of starting from scratch.

[richtabor]

Random idea: Color sets could even be defined behind the scenes (i.e. auto-generated slugs) so that color-set-1 is mapped to another theme's color-set-1. Or any color set could be mapped to any other, like if WordPress provided color palettes like it does patterns.

[justintadlock]

As I've been building out a theme, I realized that my color system simply wouldn't easily transfer from style variation to style variation (or to child themes). What I needed were color "groups" or "sets" that I could apply to entire sections, particularly with custom patterns. Basically, I needed a system where color slugs just didn't matter.

So, I'm very much interested in seeing this feature happen because it would solve a ton of issues.

Currently, I've been exploring this as custom block style variations, and defining these "color sets" via settings.custom in theme.json.

color-set-001.webm

[Ren2049]

@justintadlock I suggest a switch from the RGB based model in WP to a more apropriate one for color picking because this would enable contrast slots and programmatic color palettes which aren't possible with RGB based models.

This little blog about the topic is worth reading: https://bottosson.github.io

Here's a color picker using this model: https://ok-color-picker.netlify.app/

What color palette designers who work with RGB do (e.g. Steve Schoger from Tailwind CSS/Refactoring UI) is they componesate for RGB based color shifts and inconsistency manually using contrast checkers and by rotating the hue to better saturated neighboring hues. This works for a small palette with a handful of hues liek the one in Tailwind, but could be automated with a model like OKHSx and work with any user provided brand color.

Color sets could become contrast sets, where users then just paste in the hex code of their logo/brand color and get a working palette with accessible colors in return.

[aaronrobertshaw]

An initial proof of concept for this feature is available in #56234.

As explorations into implementing colorways evolved it became clearer that these overlap greatly with the proposed section-specific theme.json which should now also live under Global Styles.

The plan for WP 6.5 is to deliver an MVP that is code-only except for a minimal UI to facilitate the application of predefined section styles.

Allowing users to create their own section styles via Global Styles we'll likely need significant UI updates and perhaps even an overhaul to the Global Styles IA. It's for this reason that work will be pushed back to the following release.