Designing Style Variations for Twenty Twenty-Three: The Good, the Bad, and Everything Else

Since the release of Twenty Ten, the WordPress community has gotten a new default theme almost every year. This has allowed the platform to amass a well-designed and solid body of work. However, we needed to mix things up a bit, to make theme development exciting again. The next default theme, Twenty Twenty-Three, will be a stripped-down base theme with a pool of style variations built by our design community.

And the community has not disappointed. By the deadline of August 31, theme authors had submitted over 33 variations for consideration. This was a reasonably significant turnout, considering that the project’s kick-off was less than a month before. That is not much time to create and execute a design, and some people shared multiple.

The final group of variations that will ship with Twenty Twenty-Three is set to be chosen by September 7. Not all will become an “official” variation. However, there is a discussion that proposes a separate child theme that would offer even more options.

As one of the oldest theme authors in the WordPress community, I was excited about this effort. There was no way that I could pass on the challenge of designing a custom variation. Plus, it fit in line with some of the current work I was doing in finding pain points around FSE for theme authors.

In this post, I will share my experience with building a custom style variation for Twenty Twenty-Three.

What Are Style Variations?

Style variations are one of my favorite features of modern WordPress, second only to block patterns. They allow theme authors to ship multiple design presets that users can choose between via the Styles panel in the site editor, as shown in the following screenshot:

WordPress site editor with the Global Styles panel open on the right.
Example style variations for Twenty Twenty-Three.

Style variations can be as simple as a couple of color or font changes to entirely unique designs in their own right.

Before Beginning: The Right Mindset

The thing to keep in mind when designing a custom style variation is that you are not building a theme. You are skinning an existing theme.

It is easy to get carried away with grand ideas about what is possible but only become disappointed with the limitations of the global settings and styles framework. You can change things like typography, colors, and spacing, but there are times when you’re stuck with chosen presets when they are used within templates. You also cannot arrange layout elements to your liking. That would require, at least, a child theme.

Style variations are skins with a specific set of rules that you must follow. You do not quite have the full power of CSS at your disposal, but you can do some pretty nifty things under the current standard.

Building a custom style variation is an easy introduction to modern theme development. It is a way to get your feet wet, to gain an understanding of how theme.json works.

Designing a variation for Twenty Twenty-Three was also like trying to hit a moving target at times. Because the theme was under active development during this process, it meant that anything could change on any given day. And, the more complex a style variation was, the more likely a change to the base theme would affect it. This should not be the case for established themes, but it did create additional hurdles to clear.

Stepping into the Fray: Building a Custom *.json File

VS Code editor with a theme.json file open.
JSON file for a custom style variation.

Style variations are one of the easiest onramps to WordPress theme development because creators only need to work from within one file. The usual complexities around theme development are of no concern for such a project. And, because the global settings and styles feature has a standard ruleset, it’s easy to make a few changes and see quick results.

Style variations are *.json files that live in a theme’s /styles folder. In the case of Twenty Twenty-Three, the organizational structure might look something like the following:

/twentytwentythree /styles /example-a.json /example-b.json /... /theme.json ...

Because my variation was named “Rough Draft,” it was located at /styles/rough-draft.json.

Custom variations follow all the same rules as the theme.json standard. The one exception is that variations have a title field to differentiate them from the theme’s default.

The following is an example of what my variation’s JSON file looked like:

{ "version": 2, "title": "Rough Draft", "settings": {}, "styles": {} }
Code language: JSON / JSON with Comments (json)

With the basics out of the way, the variation can overwrite anything that is defined in the theme’s primary theme.json file. A creator can do something as simple as overwrite the settings.color.palette to create a new color scheme. Or, they can configure every possible setting and style under the standard ruleset, building a massively different work of art from the base theme design.

The Good: Wow, This Is Really Cool!

Single blog post view with a featured image, title, and demo text.
Single post view of custom style variation.

I have dabbled a bit here and there with custom style variations. I have long understood their potential, but I had yet to dive into a full-blown project, particularly one that could land in front of millions of users. I don’t know that my variation submission will be a part of the curated set, but it was just plain ol’ fun tinkering with a design idea again. It was also far less stressful to not have to worry about every aspect of the theme.

Given the time constraint, I pulled my initial idea from an old theme I had created. Then, I went to work, breaking as much as anyone could break (don’t forget that I was also on a mission to find pain points).

There was a small part of me that remembered exactly why I fell in love with WordPress in the first place. I felt like that same 21-year-old kid who had just learned to edit a theme’s style.css file to make some minor color changes. This was the WordPress that I remembered from so long ago. The one where themes were not 100s of files and 1,000s of lines of code. It was about figuring out how to design for the first time and enjoying every minute of it, warts and all.

If I’m being entirely honest, I probably took things a bit to the extreme. After looking at a few other variations, I realized I had customized quite a bit more than most folks. This is not necessarily a “good” or “bad” thing. Rather, it was more of a Justin-does-not-know-when-to-stop thing.

At the time, with a looming deadline for submission, I was unable to customize every feature that I had in mind. There are simply so many possibilities that I could have continued working on this for weeks.

The Bad: Lingering Pain Points

Website homepage with a header image and a three-column grid of posts.
Homepage view of custom style variation.

Between those moments of clarity and jaunts of glee were some rough moments. These were a necessary part of the process—someone needed to experience them.

For example, why can I not control the gap between posts in a Query Loop so that it matches the spacing elsewhere in the theme? There are still missing features or design tools support. Fortunately, some of the issues I either ran into or reported upstream were fixed during this process, such as theme.json-support for the <cite> element and a duplicate background on the Code block. Plus, Gutenberg 14.0 added spacing and typography support for a boatload of blocks, both blockers for many theme authors who have tried to adopt FSE features.

The upcoming WordPress 6.1 will continue to improve the lives of theme authors who are taking advantage of the theme.json toolset. Compared to a year ago, there are far fewer of those tiny irritations.

Most of my initial issues were from building a design based on someone else’s system. It took me a bit to come to grips with Twenty Twenty-Three’s slug names, spacing presets, and similar bits. While I have a few opinions on a standard naming system, there are no right or wrong answers here. Plus, such discussions are a can of worms that would only get in the way of the theme’s progress.

I had to remember that I was skinning an existing theme. It was my job to apply my vision onto the canvas sitting in front of me. Once I was able to get in the right mindset for this project, that’s when all the fun began.


As I look over the past few weeks, I am genuinely having a hard time remembering any truly frustrating moments. What I recall the most is just having a blast building my Twenty Twenty-Three variation and testing those that others built. I cannot wait for the theme and its curated set of styles to be unveiled to the community.

2 Comments

Thank you for the brilliant write-up of your experiences building a style variation Justin. Nice work! After reading your journey; I sure hope the spacing presets (white space) are more realistic in TT3. The spacing in TT2 was AWFUL!!! By the way, how will we know which style was crafted by you when TT3 is released please?

My style was not selected as part of the default 10, but it is on GitHub as a [TT3 child theme](https://github.com/justintadlock/tt3-rough-draft) at the moment. Because there were 38 submissions altogether, we’re trying to figure out what to do with all the extras. If nothing else, I will do a more official release of my style variation as a child theme on .ORG.