Themes of the Future: A Design Framework and a Master Theme

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 gigabyte 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?

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

17 Comments


  1. 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.

    Report

    Reply

  2. “WordPress needs a solid front-end design framework.”

    In theory, maybe. The reality is, Gutenberg (for example) is so fraught with inconsistencies, quirks and whatnots, that the idea of the same process (and similar team members?) doing the same for the front-end – for 30%+ of the internet?!?!? – is an extremely difficult elephant to get your head wrapped around.

    Perhaps it would be better for WP to adopt an already proven and established framework and design system? What’s better about going this route is it doesn’t have to happen top-down. Theme studios such as yourself can form a “pact” and then pick your defacto standard. Others will follow; as following is what most of the WP community does best ;)

    Report

    Reply

  3. I recalled that the 2012 theme was often used as a starter theme and was hopeful that 2020 would play the same role. It seems though that 2020 was stripped down from its inspiration. There were probably good reasons for that but …

    @Justin Tadlock, why not have a core theme that includes a fair number of Customizer options, hooks, and “canvas” templates for landing pages? People could then create child themes or use it as a base for a fork.

    An optional standard base seems like it makes sense.

    Report

    Reply

  4. The underscores theme comes to mind. It’s already used as a base for so many themes out there, why not upgrade it into a master theme?

    I, for one would welcome it and think from a business standpoint, it’s the smart move for Automattic.

    The removal of friction that users experience when a theme/plugins don’t play right because of design decisions would be a huge benefit.

    Report

    Reply

    1. I, for one would welcome it and think from a business standpoint, it’s the smart move for Automattic.

      _s appears to be all but abandoned with a few other things in play.

      It would not suprise me to see a Gutenberg-style _s created at some point by someone but it still doesn’t tackle the issue of code parity as it pertains to a WP design framework.

      Report

      Reply

  5. Having worked on _s since its birth, I think “starter themes” or “frameworks” or whatever you want to call them aren’t a great idea unless you’re prepared to maintain them, nurture active discussions around them, and also keep them updated.

    I also do not believe that a one-size-fits-all parent theme will ever exist because themers push boundaries and are incredible designers – new becomes old quickly. As far as a component library on the front end goes, sure, but a ton of those exist already.

    Best practices and standards are a moving goal post and every year default themes push those forward. Disparity between all default themes, a “master” theme, other starter themes on the market, and innovators who like to push boundaries will continue to happen to a degree.

    I also believe that headless approaches to site building, where people can do whatever they want in something like Gatsby, on their own terms, while pulling in content from WordPress will become more popular. I’ve certainly found myself enjoying building headless themes and sites lately with a WordPress-as-content only approach.

    If given the choice between developing with a master WordPress theme (or set of components that a group of devs will create) or spinning my own stack up that I’m comfortable with, I’d probably go with the latter.

    I do think that theme developers have been a ridiculously undervalued asset in the WordPress ecosystem since long before premium themes, frameworks, starter themes, and Gutenberg existed. It wouldn’t shock me if they continue to be pushed aside for the betterment of non-theme Core, even if that means ending up with CSS classes that read like college essays.

    Report

    Reply

    1. As much as I hate to be the person that does this I’m just going to +1 this comment.

      It is not quite exactly in line with my own thoughts (not certain I’d spin up an alternative stack all the time nor that the future will be CSS only) but it is very close.

      Report

      Reply

  6. I am an WordPress user absolutely no design or programming knowledge. What would the best option be in the long term. I have been using one theme from one designer for seven or eight years. The theme is being retired with no up dates for the last 4 years. I have 5 sites and around 1500 Post with videos in the featured embed code custom field created by the theme. I now have to move the video shortcode or embed code out of each post and put it on the top of the post. It would have been alot easier if I could have just changed the theme without going through the long process.

    Report

    Reply

  7. I think it’s an interesting idea, and one that most theme-developers would welcome with open arms.
    Anyone who has ever built more than 1-2 themes knows that at their core, all themes are the same. They all have the same components. It’s just a matter of how you tie these components together and how you style them. Currently these components don’t exist, we have to create them again and again and again – each time just copy-pasting code we’ve already written – and tweaking details when needed. Every time we build a theme there’s a little voice in our head that says “I’ll just call this div `.blog-layout-whatever-because-why-not`”.
    A consistent unopinionated base that would set the foundation for everything else would be a lifesaver both for themes and plugins.
    Frameworks are good, but I always reach a point where I start stripping stuff out of them. They try to accommodate all cases and therefore by necessity include things that most people will never use. If on the other hand WP-Core had a consistent method for naming things, then everyone could just use those and there would be no conflicts between themes and plugins – provided of course they both respect their role (themes take care of appearance, plugins functionality).

    Report

    Reply

  8. It’d be a dream to design themes mainly with CSS. We could go back to the days when theme shops promised two new releases monthly. ;)

    Report

    Reply

  9. “WordPress needs a solid front-end design framework.” heck yes…

    Midway through Gutenberg development I asked “What’s the wrapper model for blocks”? Where are the standardized hooks like we had for widgets? Something like theme hook alliance in core.

    What we have now is yet another freaking _mess_ because no one seemed to think ahead that themes might benefit from a standardized wrapper for eery block such that themes (and parent blocks) could predictably control layout.

    The mythical future where themes are “skins” is predicated on the idea that blocks are classed predictably and consistently.

    Heck there are now a dozen plugins just to create “Gutenberg buttons”. Each starting from scratch, none of them even attempting to extend the core button block. Every single one using completely different HTML. As a theme developer that means I _can’t_ insure that the margin around each is consistent, I can’t insure that each inherits the right font… It’s a mess where users are left confused and ask theme developers “you said this theme was Gutenberg compatible but it’s not because these Gutenberg Blocks from plugin X don’t look like the rest of the theme”.

    Report

    Reply

    1. If WordPress really wants to be “the operating system for the web”, it better spend a lot more time figuring out being _internally_ predictable and interoperable (then maybe work on the dream of being _externally) so)

      Report

      Reply

  10. This is an interesting post.

    It touches on aspects of WordPress theming I have contemplated over the past decade. But my thoughts differ from Justin’s because — unlike Justin — I am not a designer nor am I a themer.

    But as I was writing my comment I realized I had so much to say on the topic that I felt it was best to repurpose as a blog post instead.

    So — as a teaser — I’ll just include the link to the post, and then the first half of the pull quote:

    Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and instead…(read more)

    Report

    Reply

  11. Having a blueprint parent theme and/or a standardized frontend framework would be a good idea. At least in theory.

    The problem I believe is where we are at right now.

    From a theme-developing standpoint – now with Gutenberg – we’re in this weird state where (at least some) blocks don’t provide the necessary customization options so the theme must apply its own default styling for the blocks to not feel out of place.

    Integrating with G is not easy either with the CSS class inconsistencies, etc.

    It’s this back and forth that every. single. theme. would have to go through because there’s no standard.

    In general, Guternberg is not an isolated design system like page builders are and kind of blends in with the theme.

    If we’d be able to style all the aspects of the block in Gutenberg – great.
    If Gutenberg blocks came with no styling at all and the theme would take care of things – great (well, not great and unrealistic – but in theory it would at least make sense).

    Currently, we’re right inbetween which leads to a lot of inconsitencies.

    Report

    Reply

  12. Squarespace worked this way up until the launch of Version 6 in 2012. A standardized XHTML template (for all templates) really made it easy to stylize any theme (called a “Template”) and its associated custom “Styles” (as children of it).

    Squarespace “Style Your Site” Help Guide (V5) (includes video)
    Squarespace Code Library (and XHTML Site Structure Diagram)

    This really made it easy for the end user to stylize their site. The only thing they were missing was the full site manipulation of blocks for layout positioning which is where WordPress is going now.

    With Squarespace Version 6, a lot of this template / style capability and flexibility was lost (including the ability to easily export and share a template / style as an XML file). While a designer could still customize their site to a certain degree, the tools to do so were severely limited to “make things easier”. Therefore doing any major customizations now on Squarespace requires you to be a full blown developer. It’s one of the reasons why I left the platform and love seeing where WordPress is headed now.

    Report

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.