Shared a quick overview of what’s currently underway for WordPress 5.9, as a preliminary roadmap. Some are in more advanced stages than others, but together they paint a picture of what we are looking forwards to.
A new mechanism called theme.json that allows themes to control various aspects of the block editor, from presets to settings to the appearance of blocks, was introduced in WordPress 5.8. There are some cool things that can be done with it already, but I wanted to briefly explain what I think are the more substantial and interesting aspects it starts to unlock:
Interactivity. Style attributes are a subclass of block attributes. As such, the entire block universe understands their values and the interface gets hydrated with it. This means the same ruleset a theme author uses to build a theme is accessible via a graphic interface for the user to interact with. This is huge for opening up an area that used to be closed to users (or required a bunch of ad hoc work from a theme) while also giving the theme the ability to control boundaries and defaults.
Consolidation. Remove overhead from repetitive declarations on themes, particularly around supporting block features. Themes don’t need to concern themselves with structural styles and can be freed to use CSS for specific visual flair, enhancements, and details.
Compatibility. Given it speaks the language of blocks, it is by default compatible with third party blocks provided those blocks are using the core APIs. This can be transformative for the ecosystem where you don’t need to worry if a WooCommerce block would fit with your site design — it will.
Performance. The framework can generate the right bundles on the front based on what content is used. We are barely scratching the surface here as block themes start to roll out but the improvements can be massive. A theme no longer needs to pay the penalty of loading styles for widgets that may or may not be used on a given page.
Flexibility. It opens the door for mixing and merging different block style recipes. For example, you can bring your definitions for block x and z from one theme and keep y from another. You can do this knowing there will be no selector conflicts! This makes it trivial to transfer brand definitions for a family of sites or say “I want to make the buttons of my site look like this theme” without losing any other customization. Specific customizations could also be retained if desired upon theme switching. We are also barely scratching the surface of what can be possible here.
Visual parity. It goes without saying, but the representation of visual aspects in a shared format also allows the platform to ensure the editor and frontend, no matter their setups, can be in sync. The need for editor-stylesheets (which are historically inaccurate and hard to maintain) should be drastically reduced or disappear entirely.
Patterns. This has not been mentioned much, but with theme.json it’d be fairly trivial to send the theme style specification down the wire to the .org directory as structured directives so that you can preview and browse patterns using the actual context of your theme styles!
Portability. The design structure can also be used in contexts outside a theme — think native apps, RSS feed readers, emails, agencies can control look and feel of ads, etc. There’s essentially a coded recipe for how a site looks and feels that is easy to extract values from and use in different contexts.
Accessibility. Tools that tend to be rudimentary (like color contrast) can now properly understand the context of any value because the nested scope of each block is a traversable aspect ahead of rendering time. It’d be possible to generate a higher contrast flavors of an entire site automatically. Similar with dark mode.
Admin. This is more outlandish, but there’s also the possibility to use certain definitions to customize aspects of the look and feel of wp-admin based on the current site design without having to duplicate work or target things specifically.
Recently, Vlad Olaru wrote and shared with me a thoughtful piece on the place of themes and the advent of Gutenberg in WordPress. While exchanging impressions via email he encouraged me to share my own more broadly, so here I am, true to the days in which discussion happened across blogs.
Themes, mainly premium ones, have been the integrators of the WordPress world.
This made me smile. I started my WordPress journey with themes years ago. I believe it’s important, while Gutenberg evolves to give better design tools to people, to take the perspective of theme authors for a bit. What does it mean for themes that blocks allow more design tools to be available to users?
The fact themes have been the ones to essentially establish page builders as a paradigm is a testament that their role as “integrators” has pushed the ecosystem forward and lead them to implement — often in idiosyncratic ways — what the WordPress platform wasn’t paying much attention to. Themes have the privilege and responsibility of being the closest to the user and how they experience their site, leading developers, in turn, to try to overcome shortcomings in the customization experience offered by the platform. (The difficulties of making your site look like the demo of a theme are notorious.) However, in solving these issues in a multitude of ways, often incompatible with each other, it contributes to creating a faint locking effect that permeates and hurts the user in the long term. Integration can then become the shackles of inescapable experiences.
Which brings us to the conversation about how the evolution of Gutenberg interacts with themes. There is a difference between standardizing the final interaction point (in our case, the block) and giving all integration decisions to the user (the theme role, in Vlad’s examples). That seems to be the main point of discussion and it’s worth clarifying it: providing consistent integration points through blocks, design tools, etc, shouldn’t mean handling control of the design minutiae to the user, nor removing agency from themes, but instead promoting a common way of expressing site elements that ensures a consistent customization experience.
A lot of the conversations about themes have been cast, perhaps all too eagerly, in doom-colored clouds by focusing on the underlying infrastructure and perceiving the shift at play (giving more tools to users) as one that makes every user responsible for their site design. That shouldn’t be the reality. The role of themes is not really changing. They are still meant to provide template resolvers, design parts, styles, and all its various layout decisions; the only difference is that blocks would be at the center, making things more portable and easier to customize given the editor engine understands them better. Users, in turn, will see a familiar interface for all aspects of their site’s appearance.
Perhaps the only new concept being introduced is patterns. These are design helpers to achieve more difficult layouts or beautiful designs faster, which the theme can also control and provide its own. It can be as simple as a few blocks put together or can encompass a larger area of a page. Since themes are made of blocks, it’d also be feasible to swap parts of it with another. Whether a theme is built through markup, CSS, and PHP templates, or expressed through blocks, patterns, styles, and block templates it’s still the responsibility of the theme to integrate, curate, choose, and prepare the experience in the ways it thinks it can better deliver its possibilities and its safeguards. This is not going away. If anything, it becomes more present.
Actually, the general consensus in Gutenberg is that everyone should “Embrace and enhance users being in control”.
I think this is a mischaracterization lost in the sea of impressions that is the day to day process of developing the main ingredients at play. The question is not about giving all power and responsibility to the user but about absorbing the common so that the specific can be better nurtured. That is, building the design tools that would let users interact with themes and blocks in a coherent manner, and giving themes control over its mechanisms. WordPress should provide a familiar and easy to use platform but it’s also the theme builders (soon also pattern builders), site creators, and so on, the ones that shape the final solutions users will often experience.
The systems that might be implemented (block based themes, a block style system, design tools, etc) are not necessarily to be seen as targeted directly to the end user but to the theme creator as well; and passing through them to the final user. It will remain up to the theme and site creators to decide what should be exposed and in what degree, which might vary from “absolutely nothing” to opening and locking certain aspects of the experience in a controlled and familiar way. The overarching decisions (typography, colors, design balance) should be coming primarily from themes.
If the new editor gets its way, this de-facto packaging standard for distributing whole site solutions to end-users will be gone.
Definitely not! The aim is that it would give better and more supported tools to establish these solutions in ways that are inherently compatible with the platform at large. Standardizing on these design tools should help us integrate and expand a common system but shouldn’t imply taking control away from themes. Quite the contrary, a large part of the work is going into ensuring themes can have overarching control over several visual aspects of blocks.
More to the top, a global system of styling and layout will be (eventually) put at your disposal — again, nice for one part, cognitive-freeze for the other. WordPress is becoming more capable, which is a blessing and a curse.
The styling system is primarily a way to establish a direct relationship between the theme and unaware blocks — that is, blocks that have not been created with a specific theme in mind —, in a way that the platform can recognize as appearance attributes in order to render things accurately while allowing the creation of controls to manipulate them visually on the block interface. But this is something for the theme to ultimately oversee, the same way that having a “theme editor” in the dashboard doesn’t mean it should be exposed to every end-user.
The aim is to provide a better and more integrated engine to power the theme experience, not to expose all its inner workings to all people or make it easy to “ruin a design”. That spectrum should always be in the control of those that provide the final solutions, which could be tightly determined or more open ended, depending on the needs at play.
In the end, WordPress contains multitudes and we ought to design systems that are meaningful to all.
Percy Shelley wrote in A Defence of Poetry that poets were the unacknowledged legislators of the world. To borrow the sentiment, let’s hope themes can be the acknowledged curators of the WordPress world.
Tune in for the first WPBlockTalk tomorrow, a free virtual event with speakers from all across the WordPress community. Matt Mullenweg and I will start by presenting on the latest adventures of Gutenberg and hopefully doing some live demos, so there could be dragons 🐉
The beginning of my WordCamp Europe presentation last weekend was around explaining some of the principles behind the design choices for how to gradually introduce blocks in the WordPress editing experience. Miguel Fonseca wrote a great article, titled The Language of Gutenberg, based on an earlier talk we did together at Zaragoza this year that dives more deeply on the subject.
Last week, Matt gave his annual State of the Word presentation in Nashville, reflecting on another year of WordPress and what lies ahead for the project. I had the chance to join him on stage to present a live demo of Gutenberg. I’m very glad with the reception and the good conversations that happened during the event. Still a lot to do, but I’m proud of what the team has achieved so far.