Earlier at the moment, Mark Root-Wiley revealed an in-depth proposal around standardized design tokens and CSS for WordPress. The purpose is to create a constant, customizable, and interoperable system across the design instruments in core. Primarily, he’s proposing a standardized design framework or, as he refers to it, a “shared CSS toolkit” that WordPress, themes, and plugins can depend on.
The weblog publish clocks in at practically 4,000 phrases. He additionally added a shorter model of the proposal via a Gutenberg GitHub ticket. Nevertheless, the publish expands on the thought, linking to assets that span a number of years.
I responded to Root-Wiley through e-mail. This was a topic close to and pricey to me. It has additionally been a supply of frustration from different theme authors I’ve had the privilege of speaking to over the previous couple of years. These are themers who’ve been 100% behind the block system since Day 1, not the random man within the again shouting, “Gutenberg sucks!”
The first thought I shared was that there was a little bit of fatigue on the subject. There’s a push to deliver commonplace presets to core sometimes. However, it all the time feels just like the wheels are spinning within the mud till everybody will get out of the automobile once they understand its not shifting.
Root-Wiley pointed to my 2019 publish, Themes of the Future: A Design Framework and a Master Theme, as a typical ancestor to his deep dive into the bowels of this problem. However, others and I’ve been speaking about it even earlier than the launch of the block editor in WordPress 5.0.
Partly, it’s because we had been excited concerning the potential of extra standardization. WordPress might lastly right a few of its longstanding points and usher in a utopian period of theme creation based mostly on well-designed conventions.
WordPress 5.0 rolled out theme-support flags for customized font sizes and a colour palette. The options in and of themselves had been a welcome first step, however they didn’t go far sufficient. WordPress ought to have leaped forward and set requirements from the outset.
As an alternative, we bought a mish-mash of default font dimension and colour names with no tips on what they meant. How enormous is the “enormous” font dimension? What if I must observe that naming scheme and wish one thing bigger? What ought to I title it? (For a doubtlessly instructional tangent on dimension names, see my notes at the end of this post.)
I nonetheless cringe each time I see courses like
Nevertheless, I can’t proceed bashing the errors of the platform’s previous. It’s time to look ahead. Root-Wiley notes in his publish:
I want to suggest a path towards standardizing how CSS for WordPress designs and layouts are created so they’re extra clear, environment friendly, and customizable. Not solely can this strategy simplify core types, it might handle various long-term WordPress ache factors that predate even the block editor’s launch in WordPress 5.0.
I need to see presets for the whole lot customers can choose through the block design instruments. For instance, as a substitute of setting absolute models for margins, they will select predefined sizes from WordPress and/or their theme. Nevertheless, there must be requirements for naming these presets.
Why is that this so vital? Think about setting a high margin of
20px on a block in some weblog publish. It seems to be good and matches your present theme, and also you repeat this course of dozens or extra occasions on varied parts. Then, you modify designs down the street. This may very well be a full theme change or a change through the worldwide types system. This new design implements a unique vertical spacing system.
24px may make extra sense than the
20px littered all through the positioning.
The outdated setting can be tied to a worldwide worth in a super world, not the block. This could permit it to match no matter design system is in place.
Margins are only one piece of a a lot bigger puzzle. And, presets for the varied design instruments don’t even cowl the whole lot in Root-Wiley’s proposal. That’s the reason I encourage all theme and plugin authors to assessment it.
There are a number of objects I disagree with within the proposal. Nevertheless, these contain the low-level implementation work, not the idea of making a standardized system. I had deliberate to debate these intimately, however doing so would get into what a former staff member I labored with known as “weed discussions.” They get in the best way of the massive image.
If there may be one factor Root-Wiley and I agree on, it’s that huge image of making a CSS toolkit to hold WordPress into the longer term.
A By no means-Earlier than-Revealed Checklist of Sizes
It is a little bit of a aspect tangent, however I did do a ton of analysis on dimension names following the WordPress font-size mannequin. And, as a result of I’ll seemingly by no means have a cause to publish my findings elsewhere, I’d as publish them right here.
If you happen to had been ever questioning what particular sizes are greater or smaller than others (e.g., Colossal vs. Titanic), I current to you a somewhat-educated-but-may-not-be-100%-correct checklist:
- Diminutive (2XS)
- Tiny (XS)
- Regular (Medium, Common, Base)
- Additional Giant (XL)
- Enormous (2XL)
- Gargantuan (3XL)
- Colossal (4XL)
- Titanic (5XL)
- Olympic (6XL)
- Planetary (7XL)
- Galactic (8XL)
- Common (9XL)
That’s seemingly not an exhaustive checklist, however I spent a number of weeks trying up and evaluating definitions and assets. I added a number of alternate options within the combine for reference.
I additionally needed to publish this to indicate how naming issues can break the person expertise. The typical person mustn’t have to consider which sizes are the largest or smallest. A naming system like this can be a recipe for confusion. Even when the person expertise works, the code-based slugs mustn’t confuse builders.
This identical rule applies to colours and all different presets. Naming issues is tough, however it’s even more durable when you’ve got already made a multitude and wish to repair it later. It begins on the basis, particularly when the whole lot added at the moment will probably be part of the legacy code set for years to come back.