One of the oft-repeated questions in developer circles who have closely followed WordPress’ revolution via the Gutenberg project has been: When are we going to get more responsive controls? Specifically, this question is often framed around the ability to change some design element of a block based on desktop, tablet, or mobile views.
This is an important question to ask. Designers have been having similar discussions for decades at this point. If you’ve been around long enough, you’ve likely built a few perfectly-aligned sites with tables, lived through the frustrating era of floats, and have finally come to grips with the power of flexbox and grid layouts. It’s a constantly shifting discipline.
For the last decade or so, most web designers have learned to utilize the power of media queries based on the viewer’s screen size. Web design needed to adjust to handle a rapidly-changing world where site visitors were suddenly carrying around computers in the palm of their hands or reading from the comfort of their big-screen TV in the living room. However, this proliferation of varying devices created a new problem: there are no truly standard sizes (best educated guesses, but not standards), and even if there were, it could all change tomorrow. Media queries were a good stop-gap solution, but overuse of them can also bloat a site’s CSS.
Therefore, design needed to continue evolving into something that could handle the ever-changing web. That’s where intrinsic design comes in.
What is intrinsic design?
The Merriam-Webster dictionary defines intrinsic as “belonging to the essential nature or constitution of a thing.” That begs the question: What is the “essential nature” of the web?
Part of the web’s nature is that it is constantly changing. Unlike print design where you know exactly the width and height of every page and can perfectly align everything without worrying about elements shifting, the web is a fluid medium. It always has been, and intrinsic design seeks to solve problems based on this simple truth.
Modern-day fluid typography is one of the foundational examples of this idea in action. Imagine that you wanted your h1 headings for a design to be 64px. In the early days of web design you were likely viewing this on an 800-pixel monitor and used the following CSS to handle that:
h1 {
font-size: 64px;
}In responsive web design based on media queries, you likely realized that 64px doesn’t look great on all devices. Maybe you added a media query to change it based on the device viewport, as shown in the following CSS snippet:
h1 {
font-size: 48px;
}
@media screen and ( min-width: 767px ) {
h1 {
font-size: 64px;
}
}This could quickly balloon to multiple media queries based on the number of viewport sizes you needed to target. Plus, it doesn’t really solve the problem of designing based on the nature of the web.
Following an intrinsic design method would mean to approach the problem in a way that it doesn’t matter what size the viewport is. The heading’s size can contract and expand regardless. With features such as viewport units and clamp(), this is very much possible in modern CSS, as shown in the following snippet:
h1 {
font-size: clamp( 2.25rem, 6vw, 3rem );
}This is an overly simplistic example of a wide-ranging topic, but the goal is to get theme authors to continually rethink and reevaluate the best solutions for solving problems with the tools at their disposal.
It also doesn’t mean that media queries and, potentially, container queries are not crucial elements in the designer’s toolbox. There are scenarios in which it will make sense to continue using them. However, they do not always need to be the only tools you use.
In essence, intrinsic design ensures that an individual item knows how to lay itself out, regardless where it’s used on a page.
What does intrinsic design mean to WordPress?
With the introduction of the block editor in WordPress 5.0 and, particularly, the launch of block theming in 5.8, the landscape of designing on top of WordPress changed. The ultimate goal of building sites from within the UI was becoming more and more of a reality. For the health of the WordPress project, this meant making some tough decisions about not jumping head first into adding every possible CSS property as an option in the interface.
It quickly became apparent that a slower and more methodical approach was necessary to keep the UI from creating a UX nightmare. Each new design tool could result in years of technical debt.
In addition, users can insert blocks and block patterns literally anywhere. There is no way for the theme to know in which context they are used and account for all use cases. Are the blocks in a content area with a sidebar? Is the layout full-width, wide, or constrained? Does it follow flow or flex layout? There are too many scenarios to tackle this using media queries at the block level.
The reality is that design still needs to account for fluidity in screen sizes. WordPress needed to face this problem using modern techniques while keeping a check on UI bloat.
In a Gutenberg ticket titled Responsive blocks & intrinsic web design, Joen Asmussen presented some thinking behind this approach:
Ultimately the motivation isn’t necessarily to rid ourselves of media queries entirely, but rather to explore the question: how much can a single block pattern do to be responsive out of the box? A welcome side-effect, potentially, is a vastly simplified UI for editing. Media- or container-queries could be seen as a progressive enhancement on built-in intrinsic behaviors.
It is not a problem that solves itself overnight. Instead, it is an iterative process where developers have seen the release of new tools and techniques over the last few major releases and can expect more to come.
It is also a mindset. Not only do core contributors need to think in these terms, the theming community must do the same. It must continue asking itself whether today’s methods are the right ones for tomorrow.
Tools and techniques for theme authors
At the block level, theme authors do not have much control. While it’s technically possible to write a lot of custom CSS to overrule what core WordPress is doing, it is often best to avoid that scenario. The next major update could wipe out much of your work.
This is especially true with container/layout blocks, such as Group, Row, Stack, and Columns. In almost every scenario, the general rule of thumb should be to work with what WordPress provides. These blocks and their supported features are becoming more powerful with each new release.
Where theme authors have the most control is within theme.json by utilizing typography and spacing presets.
Fluid typography
WordPress 6.1 introduced built-in support for fluid font sizes via theme.json. This feature allows theme developers to register custom sizes within a specified range to grow and shrink based on the screen size, and WordPress handles all of the complex calculations behind the scenes.
Theme authors can set all sizes to fluid or enable/disable the feature for individual sizes. The following theme.json code is a redacted example from the Twenty Twenty-Three theme and shows three examples of how this can be set via the settings.typography.fontSizes property:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"typography": {
"fluid": true,
"fontSizes": [
{
"fluid": {
"min": "1rem",
"max": "1.125rem"
},
"size": "1.125rem",
"slug": "medium"
},
{
"fluid": {
"min": "1.75rem",
"max": "1.875rem"
},
"size": "1.75rem",
"slug": "large"
},
{
"fluid": false,
"size": "2.25rem",
"slug": "x-large"
}
]
}
}
}From a user’s viewpoint this will look like a normal selection of sizes in the UI:
However, how large or small the font sizes appear is entirely dependent on the size of the screen. This is a huge win for creating typography that naturally flows with the device the reader is viewing on.
Fluid spacing
WordPress doesn’t include a fluid spacing system out of the box similar to font sizes. However, it provides theme developers with the freedom to build custom spacing presets, which means they can add any valid CSS values they choose, including using clamp() to create fluid margin, padding, and gap options.
The Twenty Twenty-Three theme serves as a solid example of how to implement fluid spacing presets via the settings.spacing.spacingSizes setting in theme.json. The following is a redacted example of the JSON code from the theme:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"spacing": {
"spacingScale": {
"steps": 0
},
"spacingSizes": [
{
"size": "clamp(1.5rem, 5vw, 2rem)",
"slug": "30",
"name": "1"
},
{
"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
"slug": "40",
"name": "2"
},
{
"size": "clamp(2.5rem, 8vw, 4.5rem)",
"slug": "50",
"name": "3"
}
]
}
}
}There are several online tools for calculating the clamp() values and even formulas for doing it on your own, such as this clamp tutorial from Smashing Magazine.
Adding custom presets works well by providing end-users a simple slider in the UI for adjusting margin, padding, and gap on blocks that support any of those options, as shown in the following screenshot:
Users do not have to worry about what these odd-looking values are. They simply work regardless of what screen size their visitors are viewing from.
For theme authors, this is a powerful method of integrating existing CSS features into the WordPress global styles system.
Props to @colorful-tones for an early draft of this post and @annezazu, @mburridge, @matveb, and @bph for feedback and review.
Leave a Reply