WordPress By

Earlier today, Mark Root-Wiley published an in-depth proposal around standardized design tokens and CSS for WordPress. The goal is to create a consistent, customizable, and interoperable system around the design tools in core. Essentially, he is proposing 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 clocks in at nearly 4,000 words. He also added a shorter version of the proposal via a Gutenberg GitHub ticket. However, the post expands on the idea, linking to resources that span a few years.

I responded to Root-Wiley via email. This was a subject near and dear to me. It has also been a source of frustration from other theme authors I have had the privilege of talking to over the last few years. These are themers who have been 100% behind the block system since Day 1, not the random guy in the back shouting, “Gutenberg sucks!”

The primary thought I shared was that there has been a bit of fatigue on the topic. There is a push to bring standard presets to core every so often. But, it always feels like the wheels are spinning in the mud until everyone gets out of the car when they realize its not moving.

Root-Wiley pointed to my 2019 post, Themes of the Future: A Design Framework and a Master Theme, as a common ancestor to his deep dive into the bowels of this issue. But, others and I have been talking about it even before the launch of the block editor in WordPress 5.0.

In part, this is because we were excited about the potential of more standardization. WordPress could finally correct some of its longstanding issues and usher in a utopian era of theme creation based on well-designed conventions.

WordPress 5.0 rolled out theme-support flags for custom font sizes and a color palette. The features in and of themselves were a welcome first step, but they did not go far enough. WordPress should have leaped ahead and set standards from the outset.

Instead, we got a mish-mash of default font size and color names with no guidelines on what they meant. How huge is the “huge” font size? What if I need to follow that naming scheme and need something larger? What should I name it? (For a potentially educational tangent on size names, see my notes at the end of this post.)

I still cringe every time I see classes like .has-luminous-vivid-orange-background-color.

However, I will not continue bashing the mistakes of the platform’s past. It is time to look forward. Root-Wiley notes in his post:

I would like to propose a path toward standardizing how CSS for WordPress designs and layouts are created so they are more transparent, efficient, and customizable. Not only can this approach simplify core styles, it would address a number of long-term WordPress pain points that predate even the block editor’s release in WordPress 5.0.

I want to see presets for everything users can select via the block design tools. For example, instead of setting absolute units for margins, they can choose predefined sizes from WordPress and/or their theme. However, there should be standards for naming these presets.

Why is this so important? Imagine setting a top margin of 20px on a block in some blog post. It looks good and matches your current theme, and you repeat this process dozens or more times on various elements. Then, you change designs down the road. This could be a full theme switch or a change via the global styles system. This new design implements a different vertical spacing system. 24px might make more sense than the 20px littered throughout the site.

The old setting would be tied to a global value in an ideal world, not the block. This would allow it to match whatever design system is in place.

Margins are just one piece of a much larger puzzle. And, presets for the various design tools do not even cover everything in Root-Wiley’s proposal. That is why I encourage all theme and plugin authors to review it.

There are a few items I disagree with in the proposal. However, those involve the low-level implementation work, not the concept of creating a standardized system. I had planned to discuss those in detail, but doing so would get into what a former team member I worked with called “weed discussions.” They get in the way of the big picture.

If there is one thing Root-Wiley and I agree on, it is that big picture of creating a CSS toolkit to carry WordPress into the future.

A Never-Before-Published List of Sizes

This is a bit of a side tangent, but I did do a ton of research on size names following the WordPress font-size model. And, because I will likely never have a reason to publish my findings elsewhere, I might as post them here.

If you were ever wondering what specific sizes are bigger or smaller than others (e.g., Colossal vs. Titanic), I present to you a somewhat-educated-but-may-not-be-100%-correct list:

  • Diminutive (2XS)
  • Tiny (XS)
  • Small
  • Normal (Medium, Regular, Base)
  • Large
  • Extra Large (XL)
  • Huge (2XL)
  • Gargantuan (3XL)
  • Colossal (4XL)
  • Titanic (5XL)
  • Olympic (6XL)
  • Planetary (7XL)
  • Galactic (8XL)
  • Universal (9XL)

That is likely not an exhaustive list, but I spent several weeks looking up and comparing definitions and resources. I added a few alternatives in the mix for reference.

I also wanted to post this to show how naming things can break the user experience. The average user should not have to think about which sizes are the biggest or smallest. A naming system like this is a recipe for confusion. Even if the user experience works, the code-based slugs should not confuse developers.

This same rule applies to colors and all other presets. Naming things is hard, but it is even tougher when you have already made a mess and need to fix it later. It starts at the foundation, especially when everything added today will be a part of the legacy code set for years to come.