Hi Reader,

In 2018, I built my first website using the block editor. This was before the new editor was in Core, so it was very early.

Back then, color and font size palettes were the only customization options available. This website used both, but my approach to implementing these palettes bordered on carelessness.

I just took the list of sizes and colors I got from the designs and threw them into the code. This was right before launch, as an afterthought.

Things have changed a lot since then. Nowadays, fonts and colors are the first theme features I implement, and I give a lot of thought to how to structure them best.

In this email, I want to share the three color palette structuring approaches I've used throughout the years. We'll see their benefits and downsides and which one I prefer today.

Quick reminder: How color palettes work

Three attributes define each color in a palette:

1. Color: Usually a hex code, but any CSS color declaration is valid.
2. Name: The name displayed to the user in the block editor interface.
3. Slug: The unique identifier for this color.

Out of these three, only the slug can’t be changed at a later time. And that for two reasons:

1. The slug is part of the CSS class WordPress adds to elements using this color.
2. The slug is used to reference this color in style declarations.

That being said if this is a client project, and you have full control over the theme code and the database, you can change the slug. But you then also need to do a search-replace in all the code, and the database to update any uses of the old slug.

Quick reminder: What’s the sorting order in the palettes?

Out of the box, WordPress shows the colors in the order that they are in theme.json.

Beware that while you can control this manually, exporters will not respect your choices. WordPress and the Create Block Theme plugin will sort the theme.json properties from A-Z.

Therefore the only way to control the order is by using the right naming strategy.

Naming Strategy 1: Color names

This is the one that most developers default to: name the colors for what they are—so red, green, blue, etc.

If you are building a custom theme, this is a valid strategy. But there are three downsides to this:

First, if you do an export, WordPress will sort the colors from A-Z. And hereby, any grouping of the colors you created might get mixed up.

Second, it gets a bit tricky if you have variations of the same color. Do you call this light grey, grey, or dark grey?

In such instances, it’s often easier to use numbers for the names: Grey 1, Grey 2, Grey 3,… For the slugs, you can use increments of 10, so grey-10, grey-20, grey-30,...

Third, if you use style variations, the color names will no longer correspond to the actual colors. In a client project context, style variations are rare, so this doesn't matter as much.

So while I'm not discarding this strategy entirely, it comes with many gotchas. Because the more colors you use, the more inappropriate this naming scheme becomes.

Naming Strategy 2: By primary usage

This is the strategy that Twenty Twenty-Two used. It has a background (white) and foreground (black) color.

At first sight, this makes sense: the common scenario is that pages have a white background with black text. However, this doesn't make sense for cases like buttons, which use an inverted color scheme: black background and white text.

Twenty Twenty-Three improved on this by using base and contrast. White is the base; black is the contrast.

However, you can still use contrast as a background, with a base color for the text color in the case of buttons.

Both these themes struggled with naming any other colors. They used primary, secondary, and tertiary as names.

The issue is, though, what is a primary color? Twenty Twenty-Two is mainly black and white. So, shouldn’t the primary color of these themes be one of these?

Furthermore, the tertiary color is off-white, which hardly seems to match the two other colors.

Also, terms like “tertiary” are hard for most users to understand.

These two themes allowed us to learn the following lessons:

1. Don't tie colors to their desired usage.
2. Keep color choices relevant.
3. Avoid names that are too clever.

Therefore, I avoided this naming strategy. After the release of Twenty Twenty-Two, my approach was to use base and contrast for the background and foreground, and then color names for the rest (so red, orange, etc.).

Naming Strategy 3: Base, Contrast, Accent

This is the approach that Twenty Twenty-Four takes, and in my view, it’s the best.

This theme uses base for background color, and contrast for the foreground colors. For most color schemes that are either white or black, this makes a lot of sense.

For all other colors, it uses the term accent. Now, the word accent is a bit nebulous, but in general, the job of these colors is to draw attention to an element.

It’s not perfect, but it gets close.

As there are only three possible names, variations of the same color get a number added. So Base 1, Base 2, Base 3,... while it's abstract, it's still simple and unopinionated.

Limits of naming strategies

As you’ll discover in your block theming journey, the best naming approach cannot overcome bad design.

Here is a screenshot of a color palette used on a project I’m working on.

No clever naming can overcome this color palette, especially because we didn't have all the designs from the start of this project. Therefore, I kept adding colors to the palette as the build progressed.

So, what’s the best solution here? It's to keep it simple. I named the colors color 1, color 2, color 3,... It's impossible to make sense of a design you get delivered piecemeal, so don't even try.

Making the most of color palettes

What I've learned from this project was that:

1. Color palettes need to be fixed in advance.
2. Colors must be consolidated (the palette has two similar yellow and green tones).
3. Colors should be limited to a max of 12.

This is not always possible if you have no control over a design. But strive to work with the designer to have a solid palette. It will make not only your life but also that of the people using the CMS a lot easier.

Now, this was my experience. If you have any tips, I'm happy to hear them.

Cheers,
Fränk