Gutenberg project lead Matías Ventura announced the Preliminary Road to 5.9 on the Make Core blog earlier today. He covered several big picture items, including several sub-points for each. He also linked to a GitHub issue with specific tasks and tickets that need work.
covers notes on block patterns, navigation menus, the theme.json interface (global styles), design tools, and editing flows for block themes. There is a lot of information to take in and enough areas to cover various interests.
The most exciting focus of 5.9 might just be going deeper into responsive design at the block level, whether this is under-the-hood code or block options available via the UI.
“One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level,” wrote Ventura. “This needs to be solved in a way that doesn’t disproportionally increase interface complexity.”
Intrinsic Web Design With Blocks
It is easy to become disgruntled at the slow progress toward responsive block options over the last few years. I am not entirely unhappy with it because I want the team to be methodical and approach this in a future-proof way, at least to the extent that it can.
Far too often, what we have seen with requests and even third-party plugins is the use of viewport-based media queries for controlling how blocks respond to different devices (e.g., desktop, tablet, and mobile). While such controls can sometimes be the right tool for the job, they are not always the correct path for component-based design.
Media queries tend to favor holistic design methodologies. However, component-based design is the modern face of the web. Blocks are just another component, and because developers or even users can place them anywhere in the overall design, we must approach how they respond to their surroundings more so than the browser viewport.
“The block model is a good case to apply some intrinsic design principles, since a block can occupy a place in many different layouts and containers, for which prescriptive media queries that don’t take context into account are inflexible,” wrote Ventura.
A simple example to look at is the core WordPress Columns block. We could easily add media query options for when each inner Column block breaks. However, how should the typography respond for three columns vs. four and at different widths? That is a function of the container’s size rather than the viewport.
And, how do such media queries work when Columns are nested within another Column? This becomes a more complex problem to solve if you are putting layout controls into the hands of users. Pushing the fast-forward button on responsive block options might feel good at the moment, but it could also create legacy baggage that will be hard to drop when a better solution rolls around.
Even something as seemingly simple as a basic website header can become complex when designing for user input. For theme designers, there is no way to know how many characters are in the site title, for example, or how many items are in the nav menu. The block system can complicate that further by allowing end-users to drop in other unknowns.
“Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens,” wrote Ventura. “For this to work well, container blocks need to absorb more layout controls.”
He also mentioned container queries as a possible expansion point when they are fully supported by browsers in the future. Chrome Canary currently has a support flag to enable the feature.
Container queries are a bit of a Holy Grail for designers. As web designer Ethan Marcotte wrote four years ago:
Maybe I’ll start here: in the last few years, my design work has focused much more on patterns, and less on “pages.” Instead of treating a responsive design as a holistic, unified thing, where every part of the layout changes and adapts at the same rate, it’s more helpful to break a responsive layout down into smaller, reusable bits of design, including things like “masthead,” “footer,” “image caption,” and so on.
In other words, my design process involves looking at a responsive design as a network of small layout systems. Each of those components are basically little responsive designs themselves, with their own sets of breakpoints.
Sound familiar? Yes, the WordPress block system is built on that same foundation of small layout components.
Anything that WordPress does today at the UI level needs to account for the container queries of the future. Or, at least make use of existing tools that could replicate the feature in some ways, such as the min(), max(), and clamp() CSS functions.
The trouble is figuring out which features should be exposed as block options vs. being handled under the hood. The development team must strike a balance between the user experience and flexibility for designers. Some things should “just work” out of the box, and others should be configurable on a case-by-case basis.
This should be one of the more interesting, complex, frustrating, and rewarding problems to solve in the WordPress 5.9 cycle. For those looking for a challenge, it might be the perfect entry point.
