WordPress Developer Blog

Intrinsic design, theming, and rethinking how to design with WordPress

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.

25 responses to “Intrinsic design, theming, and rethinking how to design with WordPress”

  1. John Hooks Avatar
    John Hooks

    Thank you for this article! I’m new to WordPress development and been trying to immerse myself in the environment, and I’ve heard the term “Intrinsic Design” used multiple times and needed help putting it in context in the world of WordPress.

  2. Simone Maranzana Avatar

    The “intrinsic” approach is really powerful, but cannot be considered the only way to build a website.

    The lack of a structured data for queries (both media and container) is an issue, that every developer of plugins (or themes) is forced to solve it in different ways, none of which are part of theme.json and the style engine.

  3. Sam Avatar

    Containers are a growing issue for us, the inability to define a range of container sizes. Instead asking content writers to remember and define pixel values on a group block.

    1. Carolina Nymark Avatar

      You can use group block variations with pre-set widths that your users can insert.

      1. Simone Maranzana Avatar

        Block variations cannot be combined, so you can end up pretty soon with a ton of variations, we have experience this issue in a project last year, if you want to rely on the core functionality is really hard to make the things works fine for the end user.

        1. Greg Ziółkowski Avatar

          I found an issue in the Gutenberg repository that proposes precisely that: https://github.com/WordPress/gutenberg/issues/14598. It was opened 4 years ago!

          1. Justin Tadlock Avatar

            Block variations and block style variations (block styles for short) are different things. The recommendation from Carolina above was to use the former, but the ticket is for the latter.

            Block variations allow you to set the attributes for a block. This variation can be inserted like any other block. Block styles are essentially glorified HTML classes that can be applied to a block.

            While the ticket on block styles was opened four years ago, a solution to the existing problems with the proposal haven’t been solved yet, primarily dealing with styles meant to be mutually exclusive. Joen Asmussen recently commented and left what would be a great starting point in approaching this problem to adding multiple classes.

    2. Justin Tadlock Avatar

      It’s long been on my wish list to have more than the current width-alignment settings. There’s an open ticket that I both recommend following and noting your feedback/support on.

      Variations or patterns would be my current go-to solutions. But, if they are not flexible enough for a particular use case, I would add a custom control to the Group block sidebar for handling it (also, I’m mentally noting that we need a good tutorial for appending custom controls).

  4. Marius Avatar

    Thank you for bringing this topic up.

    The block themes truly make things easier, but without the ability to add custom CSS in the block editor, it still limits creativity.

    1. Birgit Pauli-Haack Avatar

      Hi Marius. Thanks for reading! As highlighted in our “What’s new for developers (February 2023)” post, Custom CSS is coming to WordPress with the veresion 6.2, scheduled for March 28, 2023. You can already test it via the WordPress 6.2 Beta 3 version

      1. gyurmey Avatar

        Thank you Birgit!

        I can’t seem to find that information. I only see mention of custom CSS in Site Editor (not Post/Page Editor). Have I missed something?

      2. Simone Maranzana Avatar

        Any plans to add a syntax highlighter on the CSS editor? Because is really easy for a non tech-savvy user make mistakes, and the only “warning” is a little red icon in the bottom right corner, almost invisible. A global CSS editor should be considered, because block themes doesn’t support style.css file.

        1. Justin Tadlock Avatar

          I cannot say for sure about syntax highlighting, but I know there are plans for inline code completion and linting. I don’t expect that until WordPress 6.3. The goal is at least parity with the “Additional CSS” section in the customizer, and I expect to see syntax highlighting as a part of that.

          Block themes do support style.css. Support for loading and using stylesheets should always be around.

          1. Simone Maranzana Avatar

            You’re right Justin, my bad, and thanks for the clarification about the syntax highlight.

            I mean that out of the box the Twenty Twenty Three theme doesn’t load the style.css file (and in the theme.json mindset should not be used), so a non tech-savvy user is not able to paste even a simple CSS code (a generic one, not related to a specific block) without loading the file creating the functions.php file and enqueue it (not straightforward for someone that doesn’t understand PHP).

            The entire philosophy of the Site Editor (and block themes) is to provide a no-code tool, by encoding all the CSS rules in a theme.json file (so can be discouraged the use of a style.css file), but the “responsive” behavior cannot be achieved only with an intrinsic approach and the lack of a structured data for the queries (media or container) is a big issue.

            Even with a “intrinsic mindset” the users still asks for a more specific and precise control over some basic components like the columns block, and on a project with a custom design is really easy to need that kind of control, and I don’t think that is a good idea to write a media query in the CSS textarea of the block, is the kind of data that must be configured and shared globally.

  5. Tommaso Avatar

    Hey, thanks for sharing!
    I’m not a developer so I wasn’t aware of intrinsic design.
    I can write some CSS but I generally take the no-code approach.
    I think intrinsic design is very interesting, but as you said,it has some limitations.
    In my websites and ecommerce stores, the header menu is designed differently on mobile and desktop:
    on desktop the logo is small and on the left, with the menu on the right.
    On mobile the logo is bigger and centered. The menu is off canvas.
    And sometimes I have certain parts of the page that are only shown on desktop and not on mobile, or that are completely different on mobile and desktop and this require building two different designs and showing each one of them depending on the viewport.
    This is easily achievable with Elementor and with any other wordpress page builder, and it’s even possible with Kadence Blocks, but unfortunately not with Gutenberg out of the box.
    And since Gutenberg is also designed for no-code users, I think this responsive controls are required: ultimately this is the end goal of wysiwyg tools: not write code.
    I personally think that FSE is not production ready until it has responsive controls.

    1. Justin Tadlock Avatar

      Thank you for your feedback. It is great hearing from non-developers on how they are using WordPress too.

      The goal is not for every piece to forever be stuck without any responsive controls. Intrinsic design is more about the foundation and making sure that every block can lay itself out naturally, regardless of where it’s placed. The more coverage that we can get there, the more robust the design system will be in the long term.

      Then, especially after gathering feedback like yours, contributors can start filling in those gaps that are missing from the developer tools and user controls. Additional responsive controls will then be an enhancement on top of a more solid system.

      Also, there’s absolutely nothing wrong with using plugins to upgrade the default experience. The one thing that WordPress truly excels at is being extensible. I’ve heard a lot of great things about Kadence Blocks.

      1. Tommaso Avatar

        Thanks for your reply.
        Correct me if I’m wrong, from what I understand it seems like Intrinsic design makes every block and element the right size and position regardless of the viewport size, so it should work fine for 90% of the times.
        Then, if you want something more specific, like in the case I described above with an element centered on mobile and aligned left on desktop, you need responsive controls.
        Is that correct?
        I think this is a valid approach, but unfortunately, especially in order to build websites and stores that have specific design requirements, responsive controls are needed.

        I agree that extensibility is a great thing for WordPress, however I think that standardizing the experience for very common use cases is also needed, otherwise if I have to install another plugin for such a basic requirement, I can go all in and use Elementor, Breakdance, Divi, etc and style the entire website.

        1. Justin Tadlock Avatar

          Just to make sure I’m 100% clear, neither I nor the core devs are arguing that additional responsive controls are unnecessary. The approach is about exploring what modern features (including but not limited to the intrinsic design concept) can be used before dropping in a lot of new settings fields and making the user experience worse or creating technical debt. And, this is especially true while the site editor is still in this beta phase.

          Once most of those options are exhausted, then progressively enhance the user interface with responsive controls as needed.

          This is also the Developer Blog, so the goal is to start getting theme and plugin authors to think about solutions from different viewpoints. In time, my hope is for the entire development community to create better solutions for users. Maybe that includes responsive controls for every block; maybe it’s something none of us have thought of yet.

          Then, if you want something more specific, like in the case I described above with an element centered on mobile and aligned left on desktop, you need responsive controls.
          Is that correct?

          It might be the correct solution. There are some more modern techniques that could potentially handle the use case without additional responsive controls based on media queries. Without getting too far into the weeds of the specific scenario, there might be a flexbox-based solution for that. And, that’s what this article is about—getting developers to explore some of these other solutions.

          So much more is possible in the world of CSS in the last few years compared to when media queries were introduced (about 12 years ago, I think). The hard part is figuring out how to best represent those solutions in the UI and to also do them in the most performant way possible on the front end.

          Believe me, it’s tough to wait around for those features/solutions to land when you just need to do something on your website now. I feel like I’ve been there my entire career. That’s why I’m an advocate of using plugins to bridge the gap between what WordPress currently does and what you need. Plugins can explore and iterate on ideas much faster than WordPress, which is a good thing.

  6. Andrei Chira Avatar

    We’re always trying to educate, but it’s terribly hard to get people to do things the WordPress way, and use the tools that WordPress provides out-of-the-box, not just as a skeleton on top of which to put a bloated buider.

  7. Huang Avatar

    Custom CSS for each individual block and on every post/page. This should be high priority.

  8. Rob Glidden Avatar
    Rob Glidden

    Short comment:

    Intrinsic design isn’t the future of the modern Web platform, it is the present. And has been so for a while.

    I’d like WordPress to fully, not “incrementally”, embrace intrinsic design. Grid block, Responsive block, and Flex block.

    I understand the perception that css grid is “hard to abstract” in a UI. To me the key is that “all abstractions leak”, the architecture maxim says. That’s a good thing when its the modern Web.

    Longer comment:

    “Intrinsic design” was coined in 2018 – search for “Everything You Know About Web Design Just Changed” by Jen Simmons.

    Jen meant the new design options enabled by the modern web features that were then just rolling out — particularly flexbox, grid and viewport units (horizontal and vertical). With media queries as a useful fallback.

    Interestingly, Gutenberg was architected circa 2017 — a transition era when the modern Web was already envisioned and standardized, but not yet fully deployed. So architects had to use transition “bridges and hacks” like React, bundling, and an architecture philosophy of “incrementalism”.

    But 2023 isn’t 2017. The modern Web is here. And even more intrinsic design-ish stuff in the pipeline.

    Let’s say WordPress had a intrinsic design grid block and a responsive block:

    Responsive block. You’d put in different inner blocks for different viewport sizes as you saw fit.

    There are already many blocks that show different inner blocks based on some logical condition — for example I wrote one to show different inner blocks depending on whether logged in or not.

    Grid block. A full-featured grid block is a challenging UI, because css-grid has many features. But same basic idea of different inner blocks in different grid areas.

    My guess it will be very tempting to take the old-fashioned “incrementalism” approach and roll out a simplified grid block version.

    But I for one think it would be better for WordPress to drop circa-2017 incrementalism.

    The group, row, stack and nav blocks are fine as far as they go, and simplification abstractions have their place.

    But wysiwyg is about the “what you get” part — i.e. the modern web. Not a Figma auto layout feature that evolves for years.

  9. lesley.pizza Avatar

    Thanks for this Justin. It gave me a *great* foundation to understand all of this stuff.

    It’s especially useful given how much chatter there is about the lack of responsive controls. As someone who has griped a lot about this, it’s great to:
    1. understand how everything is conceptualised/architected on a high level
    2. know that the lack of responsive controls is acknowledged by core devs and has not been ruled out.

    I also thought the comments here were really helpful as well as it gave additional perspective and helped me know what others in the community are thinking.

    I’m so glad you’re here writing about this stuff!

  10. Mateus Machado Luna Avatar

    I’m 100% in for the responsive “intrinsic” solutions that we have so far. Both fluid font sizes and spacing are way better than setting spacing for separate devices (I’ve been working with this in Elementor and it can be painful).

    The greater argument for me is that designs should not be defined by devices, because as you pointed, we cannot see what is coming next (SmartTVs, SmartWatches???). I’ve never being 100% satisfied with my layouts when in-between breakpoints like mobile-to-tablet. What about ladscape? What about high-res? What about freaking window tilings??

    So yes, that seems the way to go. That said, I think you guys already recognize that there are situations where we need a “breakpoint”. I don’t like to plan this breakpoints by container size, but mostly by content size. In my opinion, no matter how much we try to avoid, there are two scenarios that we are not covering…

    1 – Overlays. They are part of UI/UX for decades and the very fact that Gutenberg already does this in the mobile menu shows that we need an official and configurable solution for this. How serious it is that we cannot define a breakpoint/condition to decide when the toggle menu should appear? I get that not every menu must be a collapsible panel, but haven’t we accepted that sticky headings were a thing? If so, we do admit some things must be placed above others. If we have an official solution for this, those eager to build smartphone-ready UIs will take benefit and those that are OK with a more traditional layout will still take benefit.

    2 – Carousels. I’m fine with them being available only via plugins because I understand how complex it is to add a Swiper.js dependency. But to be honest, for any UI with large lists of contents, it is so meaningful to have a simple horizontal-scroll list instead of breaking columns into rows… We may not have fancy arrows and transition animations, but we could be using them to overflow content that we do not want to be squeezed in a column. And maybe, using a bit of “scrol-snap” magic, the experience could be improved without needing layers of Javascript.

    Just a few considerations. Hope we can evolve on this topic.

  11. Nikos Kyimas Avatar
    Nikos Kyimas

    Thanks for this excellent article, indeed intrinsic design is an exciting approach and it makes sense for font sizing and spacing but what about grids and columns?
    The way Gutenberg columns/row blocks work now gives little control over to the editor to create this type of concept. I mean as far as I can understand the tools that are used for fonts and spacing (clamp,max,min) can’t be used for columns. Is there any example/workaround for a custom block with a complex layout using this approach?

    When I think how intrinsic design can be used to create a new custom theme for a client and let the client use Gutenberg columns as their default columns block I can’t find any viable solution without any responsive controls and I think maybe I’m missing something…

    1. Birgit Pauli-Haack Avatar

      Thanks for reading the post and taking the time to comment. You are right the columns blocks, doesn’t provide Other methods of responsiveness are built into the Group block, with the Row and the Stack variations using flex and flow layouts. You might want to explore a few scenarios with those options.

Leave a Reply

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