The Case for a Shared CSS Toolkit in WordPress – WP Tavern

Earlier today, Mark Root-Wiley published a detailed article proposal around standardized design tokens and CSS for WordPress. The goal is to create a coherent, customizable and interoperable system around the kernel design tools. Essentially, it offers a standardized design framework or, as it calls it, a “shared CSS toolkit” that WordPress, themes, and plugins can build upon.

The blog post is almost 4,000 words. He also added a shorter version of the proposal via a Gutenberg GitHub issue. However, the post expands on the idea, linking to resources that span a few years.

I responded to Root-Wiley via email. It was a subject that was dear to me. It’s also been a source of frustration for other theme authors I’ve had the privilege of speaking with over the past few years. These are themers who have been 100% behind the blocking system since day one, not the random guy in the back yelling “Gutenberg sucks!”

The main thought I shared was that there had been a bit of fatigue on the subject. There’s a push to bring the standard presets to heart from time to time. But, it still feels like the wheels are spinning in the mud until everyone gets out of the car when they realize it’s not moving.

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

This is partly because we were excited about the potential for greater standardization. WordPress could finally fix some of its long-standing issues and usher in a utopian era of well-designed convention-based theme building.

WordPress 5.0 rolled out theme support flags for custom font sizes and color scheme. The features themselves were a welcome first step, but they didn’t go far enough. WordPress should have taken a leap forward and set standards from the start.

Instead, we got a hodgepodge of default font sizes and color names with no indication of what they mean. What is the “huge” font size? What if I need to follow this naming scheme and need something bigger? How should I name it? (For a potentially educational tangent on size names, see my notes at the end of this article.)

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

However, I will not continue to denounce the mistakes of the platform’s past. It’s time to look to the future. Root-Wiley notes in his article:

I would like to propose a path towards standardizing the creation of CSS designs and layouts for WordPress so that they are more transparent, efficient and customizable. Not only can this approach simplify basic styling, but it would fix a number of long-term WordPress issues that even predate the release of the Block Editor in WordPress 5.0.

I want to see presets for anything users can select through 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 some standards for naming these presets.

Why is this so important? Imagine you set a top margin of 20px on a block in a blog post. It looks good and matches your current theme, and you repeat this process dozens of times or more on various elements. Then you modify the designs along the way. This can be a full theme change or a change through the global style system. This new design implements a different vertical spacing system. 24px might make more sense than 20px littered all over the site.

The old parameter would be bound to a global value in an ideal world, not to the block. This would allow it to match any design system in place.

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

There are a few things I disagree with in the proposal. However, these involve the low-level implementation work, not the concept of creating a standardized system. I had planned to discuss this in detail, but it would fall into what a former team member I worked with called “weed talks”. They obstruct the overview.

If there’s one thing Root-Wiley and I can agree on, it’s this overview of building a CSS toolkit to port WordPress into the future.

A list of sizes never published

It’s a bit of a side tangent, but I’ve done a ton of research on size names following the WordPress font size template. And, because I’ll probably never have reason to publish my findings elsewhere, I might as well publish them here.

If you’ve ever wondered which specific sizes are larger or smaller than others (e.g. Colossal vs Titanic), here is a somewhat educated but may not be 100% correct listing:

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

This is probably not an exhaustive list, but I spent several weeks researching and comparing definitions and resources. I added some 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 shouldn’t have to wonder which sizes are bigger or smaller. A naming system like this is confusing. Even if the user experience works, code-based slugs shouldn’t confuse developers.

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

Esther L. Gunn