The Case for a Shared CSS Toolkit in WordPress

The Case for a Shared CSS Toolkit in WordPress

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

[…]

 



This article was written by Justin Tadlock and originally published on WP Tavern.

Disclosure: Some of the links in this post are "affiliate links." This means if you click on the link and purchase the product, We may receive an affiliate commission.

Leave a Comment

You have to agree to the comment policy.

Show Your ❤️ Love! Like Us
Scroll to Top