One of the most powerful features of WordPress block themes is the ability to create a design system that shapes the aesthetic of your theme. This design system, powered by settings in the theme’s theme.json file, dictates the design language of blocks, patterns, templates, and how all of these elements interact with each other.

On top of that, users can customize these styles to make sweeping changes to their site within the WordPress UI. Contrary to classic WordPress themes, block themes aim to be a no-code (or very close to it) experience, empowering the user to design, build, customize, and launch their website with native controls.

This shift towards a no-code experience means that WordPress has to find creative ways of handling complex problems without overwhelming the user (many of whom are still having a tepid transition into the block era). Along the way, the WordPress UI has been growing and evolving to meet the many demands of building modern websites.

Great control, great responsibility

Now that users are diving deeper into block themes, one of the first hurdles they’re seeing is the lack of responsive controls in the WordPress UI. It’s a totally realistic expectation — virtually every other website builder has granular controls for adjusting styles for tablet and mobile views.

Now, lacking a core standard, many WordPress block solutions have started implementing their own responsive controls. Naturally, users are wondering when these controls are coming to WordPress core for a more uniform experience.

Do we need responsive settings in the block editor?

— James Koussertari (@jkoussertari) April 28, 2023

The response from WordPress core decision-makers has been varied. Some say it’s too complex to implement into the UI, some say it’s aspirational, some say fluid, or “intrinsic design” (more on that in a minute) should be enough and when you need anything more, just add CSS.

However, for creators, agencies, and freelancers who are still deciding whether or not to fully buy into the block theme paradigm, this response doesn’t really inspire confidence. For many, stopping short at responsive control feels contrary to the promise of a no-code theming future.

Yeah, I think the question becomes what needs to be in the UI, versus what would be considered more advanced functionality that can be added via custom CSS or a third-party extension.

What are some things you would like to see in the Editor itself?

— Nick Diego (@nickmdiego) April 28, 2023

This sentiment totally resonates with me. I’ve spent the last year deeply embedded in block themes, learning everything I can and creating a WordPress theme that brings all of these powerful new features together. And in my experience, we’re like 90% there. That’s how good block themes are right now!

But there’s so much potential left in that last 10%, and today I’d like to dig into how we can get closer to 100%.

The future is flexible

If you’ve been following the conversations around WordPress block themes, you’ve probably seen the term “intrinsic design” being used in different contexts. Although not a particularly new concept, it’s important to do a quick refresher as it will help inform how we think about block themes.

As coined in 2018 by Jen Simmons in her talk “Everything You Know About Web Design Just Changed“, intrinsic design is an evolution of how we approach responsive design as we know it.

• Contracting & Expanding – the way we consider how our design will adapt to a change in available space
• Flexibility – using primarily Flexbox and Grid in combination with newer units and functions in a way that enables our layouts to adapt at various rates to the available space
• Viewport – the ability to use all four sides of the viewport as well as take advantage of viewport units

Traditionally, we’ve thought of responsive design as how a design changes at certain viewport sizes (i.e. at 768px, I want the columns to collapse down to one column).

With this model, we’re essentially saying the content should transform to fit into arbitrary constraints, instead of letting the content decide when it should shift into a more appropriate layout based on its context. And with the thousands of device screen sizes to account for, aiming for breakpoints is largely a futile exercise.

Just examples on how responsiveness can be achieved without queries. The same techniques can be scaled with larger, more complex, designs as well.

I think there’s certainly room for more intrinsic design tooling, but what we have today is quickly moving in the right direction.

— Rich Tabor (@richard_tabor) April 28, 2023

Conversely, with powerful features like CSS Grid, Flexbox, container queries, clamp, min(), max(), and fit-content, we can design smarter layouts that adjust to the context in which they exist. We can and should break free from breakpoints, and start thinking of our entire design from a fluid-first approach. This is the foundation of intrinsic design.

How we’re doing so far

Realizing all of the benefits of intrinsic design will be a big effort, and will require widespread adoption of new building standards, but we’re off to a pretty good start!

Realistically, we’re in more of a fluid design phase than an intrinsic phase. (Maybe the distinction doesn’t matter?) With fluid typography, margin, padding, and spacing with CSS clamp(), we can achieve fluid and graceful scaling of common content elements, while also providing common-sense UI controls to the user. This is part of the promise of intrinsic design.

However, in order to reach that level of epic intrinsic web design, WordPress will have to lean even further into a large-scale CSS Grid and Flexbox implementation that is able to abstract away much of the complexity of grid-based layout building. On top of that, there will have to be a sustained educational effort to help theme builders start thinking and building with these principles in mind. It’s a whole vibe.

A fluid-first approach

While we work towards that bright future of native intrinsic web design, we still have a responsibility to the reality of WordPress site building today. We still have scores of veteran and novice users wondering about responsive design controls, and whether we can compete with other modern site building solutions.

At a very basic level, many of us have been mentioning this for years, but the ability to change margins, padding, font size, etc based on responsiveness is essential to be usable. Right now I know a lot of us use 3rd party plugins for this BUT at this point it should be baked in

— Daniel AwesomeSmith (@schutzsmith) April 28, 2023

In the short term, we can and should promote the adoption of fluid design as the go-to way of building block themes. By sharing fluid styles across typography, margin, padding, and block spacing, your design system can handle most of your responsive needs while keeping a beautifully-cohesive design intact across your whole site.

But, even with a comprehensive fluid design system like I’ve built into Ollie, you’re still going to have circumstances where you need to make fine-tuned adjustments (just ask anyone with a roster of clients), and media queries still have a utility here. We’re just not at that point where we can simply brush them off.

In the short term, we can and should promote the adoption of fluid design as the go-to way of building block themes

So, what do we do about that last 10%? How do we approach responsive control without being inundated with responsive controls? Can we do better than telling folks to use custom CSS? I think so, and I have a few ideas!

Exploring native responsive controls

Over the past few weeks, I’ve been contemplating how we might implement common sense responsive controls to address the gaps that fluid design can introduce.

When thinking about adding anything to WordPress, it should always be considered with a great deal of restraint. Big features are difficult to get approval on and costly to implement, so we have to keep our approach super simple, intuitive, and use as much of the current offerings as possible.

With that in mind, here are some baseline requirements that I approached this proof of concept with.

• Responsive styles should only be needed as an exception
• Responsive settings should only be shown in context
• Responsive settings should be limited to specific style settings

Only show controls in context

For starters, we have to avoid cluttering the WordPress UI at all costs. Adding persistent responsive controls that only some users need sometimes is not the right approach.

Instead, we should only show these controls in contexts where they are most needed. For this, we can tap into the Tablet and Mobile view already built into the WordPress editor.

Right now, this view just functions as a simple preview of your content at various viewports defined by WordPress. What if we took this view a little further? What if you could not only view your styles in this responsive context, but you could also contextually modify them here?

Introducing style overrides

Next, we need a mechanism for adjusting styles in this responsive view. Let’s just reuse the same UI we already have, but change its context.

In this proposal, a new menu item appears on select style settings when you are in the editor’s responsive view. Clicking Enable Style Override would turn the respective style into an override that would take precedent at that viewport size.

In this example, changing the padding slider would only affect screens below 780px (or whatever breakpoint is defined in the theme). Ideally, we default to the tablet and mobile breakpoints defined by WordPress, but allow these to be customized via theme.json.

Other than an indicator that a style override is active, we don’t really have to modify the native settings UI any further. The override can be enabled and disabled just like any other style setting via the kebab menu.

For some inline education, we could utilize the guide modal the first time the user interacts with the feature. This would be a good opportunity to set some realistic expectations and encourage the user to consider their fluid design system before adding style overrides.

All together, the flow for style overrides could look something like this. In this demo, we’ll add a style override for padding on tablet, and then remove it before returning to the desktop view.

Scaling down the scope

Returning to the idea of restraint, we have to decide what block style settings should receive a style override setting. To start, we can safely scope this down to only support settings panels that supports fluid styling, such as Typography and Dimensions (margin, padding, and block spacing).

There’s also a good case to be made about the Columns block, which currently tries to handle responsive stacking automatically. In fact, the Columns block is usually the first block where users realize the lack of responsive controls.

Iterative and intentional

What I like about this concept is that it’s iterative and intentional. It breaks away from superfluous use of breakpoint styles, and doesn’t inundate the user with new UI. Instead, style overrides are responsibly tucked away in a context where they makes sense, providing restraint to a feature that could otherwise could balloon in scope.

Wrapping up

So, what do you think of this concept? Surely, I haven’t covered every circumstance here, so I’d love to hear your thoughts. If anything, maybe this is a good fire starter to a bigger conversation.

Would a native iterative approach like this be a good place to start? What kind of needs do you have for responsive styles within your work? And have you maxed out the capabilities of your theme’s fluid design system via theme.json before considering the need for responsive controls?

This is a big conversation, so let’s hear some diverse commentary! Feel free to comment below, or start a conversation with me on Twitter.