WordPress theming has a rich history. Over the years, theme authors have brought a plethora of features to the platform. In part, it is because they have often had to solve foundational issues with WordPress to create the features that end users want.
The post and body classes all theme authors use today? Those were originally in a theme called Sandbox.
Featured images? Those were popularized by magazine themes a decade ago.
You think post formats originated with Tumblr? Matt Mullenweg, co-creator of WordPress, taught us how to create aside posts in our themes in 2004, but they existed before that.
WordPress features often get their start in the theme world. We sometimes take for granted the years of experimentation and iteration on ideas where theme authors are putting in the work. Even the block editor is handling items that have traditionally been within the realm of theme design. The cover block is a good example. For years, theme authors built theme options for a basic hero image with text and buttons overlain. The result was often clunky and not ideal for users. By bringing this feature into core, it provided users the ability to put this cover block in any permitted block area.
The reason many theme features make it to core is that they simply work better when they are standardized. Users know what to expect, and theme authors can focus on the design aspect rather than solving the user experience problem.
Part of the problem of the past is that each new feature adopted into core did not follow any standard design pattern or naming scheme. A huge skill in designing WordPress themes is committing the mish-mash of hundreds of classes to memory.
The block editor is in a unique position to change that by creating a universal design framework.
Does WordPress Need a Front-End Design Framework?
With block patterns coming in the future and full-site customization at some point after that, theme authors are wondering just exactly where this ship is sailing. It is exciting because the possibilities are boundless for end users. It is frightening for theme authors who have built their empires upon one way of doing things, but development is more about adaptation than anything else.
Armed with the foreknowledge that the landscape is changing, this is the moment theme authors need to band together to shape their futures in a block-based world.
There is a bit of a running joke in one of the developer groups I am involved in that core developers are not theme authors. From the theme author perspective, it can sometimes seem like ideas are haphazardly thrown together with no thought toward CSS design systems.
Oh, I see some BEM. Why does this sub-element not follow the same naming scheme? Wait. Is that a 38-character utility class?
What WordPress has always lacked is a universal front-end design system. At times, that has been a good thing. It has allowed theme authors to use their preferred framework. Any theme author who has been in the game long enough will tell you, that sort of flexibility is great…until it is not. Have you ever tried adding contextual classes to widgets? What about adding a utility class to the comment form wrapper? You will need an Aspirin. Or two.
With WordPress, some things are set in stone and others are pluggable. Some features follow a standard class-naming scheme and others make no sense. The result for themes is often bloated CSS in an attempt to wrangle the various components.
It is next to impossible to fully use a utility-class framework like Tailwind CSS in a theme without recreating core features.
Much of this stems from years of legacy code piling up and WordPress’ commitment to backward compatibility. But, the future does not have to resemble the past. We are at the threshold of a new era, and now is the time for front end designers to jump into the conversation.
WordPress needs a solid front-end design framework.
That is a loaded statement. If you put 20 designers in a room and ask them to discuss design frameworks, it could be a recipe for fisticuffs. I tend to be an optimist and hope the debate provided results.
Gutenberg has pushed us partially in this direction, but it does not quite go far enough. With full-site editing in the future, there is a need for a more holistic approach in tackling this problem.
More than anything, we need more front end designers in the conversation. There is no way .has-subtle-pale-green-background-color should exist as a utility class over something like .bg-pale-green, .bg-green-100, or even .background-pale-green, if you want to be more verbose. There was no concept of optimization that went into that decision. In a time where developers are running on gigabit internet connections, it is easy to forget that much of the world is following along at a slower pace.
A component-based naming scheme with a healthy dose of utility classes is one option that could hit several sweet spots. This is not an argument for one CSS framework over another. There are many good, existing options. WordPress should tackle this head on by borrowing from the groundwork laid down by other projects and creating something uniquely WordPress. It should be a leader in the field.
Design frameworks are also about plugins. There is some crossover into the realm of themes where the two have been waging an ongoing war since the dawn of the theme system. The battlefield between themes and plugins is littered with the deaths of good ideas. Far too many never garnered the support they needed to land in core. Some sort of universal design standard could stanch the flood of issues and call for a cease-fire.
A plugin that outputs a custom front-end component has no way of knowing how the current theme handles vertical rhythm, for example. Does it use top or bottom margin? What is the value and unit used? This is foundational stuff, and it is almost always broken when the plugin attempts to add custom CSS to handle it.
WordPress needs a design framework, or language, that allows all of its moving parts to come together in harmony on the front end. I am sure we will get there at some point. I hope that it is more cohesive than the random components and naming schemes of the past. We should also have a clear roadmap that fills in some of the technical details so developers and designers might be prepared.
Is a One-Theme Future Possible?
Rich Tabor makes the argument that core WordPress could provide a single parent theme in his article A Look at WordPress Themes of the Future. The idea is that theme authors would be relegated to creating a child theme for this “master” theme.
The gut reaction for many would be that it would not work, themes would lose their personality and we would live in a world of cookie-cutter designs.
The reality is that we are barreling toward a future where the idea of a single parent or master theme is a serious consideration.
Most themes are custom groupings of standard elements that exist in nearly all themes. There are some decisions, aside from stylistic concerns, that make themes different from one another, such as the layout of the header. One theme might have a site title and nav menu in one block. Another might have a nav menu, title, and a second nav menu below. Yet, another theme might show a search box. In a world where full-site customization belongs to the user, those decisions become a part of the user experience rather than the developer experience.
Themes will need to stand out with color palettes, typography, and their own brand of quirkiness — a return of the days of CSS Zen Garden but on a much larger scale.
I won’t be sad about that. It would be interesting to see the competition between the top designers in the field. It may also bring WordPress theming back to an era when anyone could do it with a little CSS knowledge and determination.
While we are not quite ready for a future in which one theme rules theme all, it is a place to start the conversation. If we designed WordPress for this potential future, even if we never implement a master theme, what would the roadmap look like? What obstacles stand in the way? Is it feasible?
Our solution for now in the publishing and B2B areas (using WP since 2004/5), has been to build our own ‘framework’ to work more like classic SHTML with SSI, which was our old preferred method – keeping the core WP functions and hooks for plugins, but adding ability to drop in snippets ‘anywhere’ from external file, simple stuff like dropping in ‘current date’ or ‘last date updated’ in middle of paragraph. We chose to hook into using Bootstrap, then remove un-used code to trim to fit. We also chose NOT to use the new box model for WP, and roll our own code using Bootstrap where pages can be built as raw HTML (ala SHTML practice). But, with templates and includes — like, why not have static drop down menu for B2B site vs bunch of queries for every page every load ? Why not have simple “duplicate page” function like us old skoolers are used to. I realize I’m a web dinosaur, but we found mixing the old methods with WP core, and turning off what we don’t want to work more like CMS vs blogger platform, has always been best course. I won’t use any more theme builders, custom themes, ‘the customizer’ and all that, which will cause my sites to become a wreck in a few years. And screw Jquery and the horse it rode in on. :-) (sorry, bit of a rant … ) My point is, WP should have ‘use containers’ where you can select a way to work from multiple theologies – default, parent, stacks, raw, which don’t blow up in 3 years killing an active site.