Today Mark Root-Wiley published a detailed proposal for standardized design tokens and CSS for WordPress. The goal is to create coherent, customizable, and interoperable systems around core design tools. Basically, he proposes a standardized design framework or, as he refers to it, a “shared CSS toolkit” that WordPress, themes, and plugins can rely on.
The blog post reaches almost 4,000 words. He also added a short version of the proposal via a Gutenberg GitHub ticket. However, the post expands on the idea and links to resources spanning several years.
I replied to Root-Wiley by email. This was a familiar and important theme for me. It’s also been a source of frustration from other theme creators I’ve had the chance to talk to over the past few years. Yes, and not some random person in the background yelling “Gutenberg sucks!”
The main thought I shared was that I’m a little tired of this topic. But it always feels like the wheels are spinning in the mud until everyone gets out of the car and realizes the car isn’t moving.
Root-Wiley pointed to my 2019 post, Themes of the Future: A Design Framework and a Master Theme, as the common ancestor that delved deep into this issue. But other people and I have been talking about it since before the block editor was released in WordPress 5.0.
One of the reasons was the excitement of the potential for further standardization. WordPress has finally managed to fix some of its longstanding problems and usher in a utopian era of well-designed, convention-based theme creation.
WordPress 5.0 rolled out theme support flags for custom font sizes and color palettes. The feature itself was a welcome first step, but it wasn’t enough. WordPress had to make the leap and set the standard from the beginning.
Instead, it was a jumble of default font sizes and color names with no guidelines as to what they meant. How big is a “huge” font size? What if I have to follow that naming scheme and want something bigger? What should I name it? (See my notes at the end of this post for a potentially educational tangent on size names.)
I still cringe every time I see a class like .has-luminous-vivid-orange-background-color.
But I’m not going to continue bashing the platform’s past mistakes. It’s time to have fun. Root-Wiley said in the post:
I would like to suggest a way to standardize how to create CSS for WordPress design and layout, making it more transparent, efficient and customizable. This approach not only simplifies the core style, but also addresses many of the long-term WordPress pain points that predated the release of the block editor in WordPress 5.0.
I would like to see all the presets that the user can select via the block design tool. For example, instead of setting absolute units for margins, you can choose predefined sizes from WordPress or your theme. However, there should be a standard for naming these presets.
Why is this important? Imagine setting the top margin 20px In a blog post block. It looks great, matches the current theme, and repeats this process dozens or more times with different elements. This could be a complete theme switch or a change made by the global style system. This new design implements a different vertical spacing system. 24px may make more sense than 20px Scattered throughout the site.
The old settings are associated with ideal world global values instead of blocks. This allows you to match whatever design system is in place.
Margins are just one piece of a much larger puzzle. Also, the various design tool presets don’t cover all of Root-Wiley’s suggestions. That’s why we recommend checking with the authors of all themes and plugins.
There are several items in the proposal that I disagree with. However, they involve low-level implementation work rather than the concept of creating a standardized system. I was going to discuss them at length, but in doing so I got caught up in what a former team member I worked with called a “weed discussion.” will get in the way of
If there’s one thing Root-Wiley and I agree on, it’s the big picture: creating a CSS toolkit that will carry WordPress into the future.
unpublished size list
As an aside, I did a lot of research on size names according to the WordPress font size model. And since there’s probably no reason to publish my findings elsewhere, I might as well post them here.
If you want to know which specific sizes are larger or smaller than others (e.g. Colossal and Titanic), Somewhat educated, but not 100% correct list:
- Petite (2XS)
- Tiny (XS)
- small
- Normal (Medium, Regular, Base)
- big
- extra large (XL)
- Extra Large (2XL)
- Gargantuan (3XL)
- Colossal (4XL)
- Titanic (5XL)
- Olympic (6XL)
- Planetary (7XL)
- Galactic (8XL)
- Universal (9XL)
This may not be an exhaustive list, but I’ve spent weeks exploring and comparing definitions and resources.
Also, I wanted to post this to show how naming can hurt user experience. The average user doesn’t have to think about what size is the largest or smallest. Such a naming system is confusing. Even if the user experience worked, developers wouldn’t be confused by code-based slugs.
This same rule applies to colors and all other presets. It’s hard to name things, but it’s even harder when it’s already a mess and you need to fix it later. Especially when it comes to being part of a code set.
