Responsive blocks & intrinsic web design

[jasmussen]

In the Preliminary Road to 5.9 post, intrinsic web design principles are outlined as a potential path forward for providing basic responsive defaults to blocks:

• One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level. This needs to be solved in a way that doesn’t disproportionally increase interface complexity.
• 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.
• Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens. For this to work well, container blocks need to absorb more layout controls. (Container queries might help expand this further in the future.)
• Typography tools need to become more fluid and internally support algorithmic clamping. Whenever possible, patterns should just work and accommodate themselves.

To distill that a bit, a lavish pattern featuring multiple columns and complex layouts might look great if inserted in a sufficiently wide theme, but it might fall apart if inserted in contexts or layouts that are narrow. Media queries (#19909) that look only at the viewport width will fail to provide good fallback views for patterns inserted into columns. Even in cases where media queries would work as intended, it might add undue complexity for basic behaviors that feel like they should be built in:

If we look at what intrinsic tools we have available, notably things like CSS grid autofit and minmax as well as clamp based algorithms, we can get quite far. The following 3 column layout collapses to 1 column when the container (or the viewport) is <480px wide:

Using clamp we can provide min/max values for font sizes:

We can create columns that stack on their own as individual columns go below a certain minimum size:

The above examples can be tinkered with in this Codepen.

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.

If we can refactor blocks to have intrinsic responsivness built-in, it's likely that we would need to evolve the design tools to accommodate some configuring of values:

• What does a font size picker look like if you can specify a minimum and a maximum value?
• What would a control that decides maximum and and minimum amount of columns in a gallery look like?
• For columns that stack progressively, would we need a minimum column-width slider?

These ideas need some visual exploration.

[joesnellpdx]

Although I love the idea of using responsive text and context aware development, I feel this should be handled by theme developers and not in core.

My concerns are that this will be very opinionated and will likely result more debt that theme developers will need to unravel, remove, or override these styles on a regular basis in custom builds. This also assumes that the solutions provided will match a majority of visual design solutions, which I am not confident it will.

I suggest leave responsive text and context aware development handling up to theme developers in core. If, however, we enable responsive text (or other context aware development), have it optional and easily removed by theme.json. Roadmap to leverage container queries (also by theme developers) as an additional holistic solution.

[cbirdsong]

I do think typography is a step too far for the core plugin, but intrinsic layout styles for stock blocks would be far better than the current ones since they will work in more contexts without theme authors needing to fight them. When doing custom theme development on projects with the block editor I've ended up disabling the stock editor styles entirely in order to replace them with intrinsic layouts.

[ouw-jvt]

[...] I feel this should be handled by theme developers and not in core.

[...] this will be very opinionated and will likely result more debt that theme developers will need to unravel, remove, or override these styles on a regular basis in custom builds.

Gutenberg already crossed these thresholds - these things need to be there, and they should be extendable by theme developers and ready-to-go for end-users. Right now we still have all of the negatives you listed but none of the controls we need (and have in other platforms).

[mtias]

The next step here should begin by having access to setting width on nested group blocks, so we can represent columns by a row + stacks. I'd love to explore min/max values for these width elements.

[strarsis]

And I also want to mention the sizes attribute for responsive <img>s that needs information about the absolute width of the element - which can be achieved in many cases by knowing the widths of its containers up to the root.

[aristath]

I agree 100% that intrinsic design is the way forward...
We live in a world where the consumer device can be anything from a 1-inch smartwatch, up to a 100-inch smart-TV. "pixel-perfect" no longer works because a "pixel" no longer makes sense when the devices vary so much. It's too limited and extremely fragile.
It's time we move towards pixel-agnostic design principles, making things easier for everyone.

The next step here should begin by having access to setting width on nested group blocks, so we can represent columns by a row + stacks. I'd love to explore min/max values for these width elements.

Last year I did an experiment with intrinsic styles for columns... (#33330)
I never finalized that PR because other things got prioritized, but the concept was working just fine. I could rewrite it and start working on it again 👍
From my experiments back then, we don't necessarily need a max value, things can work using just a min. So we can define for example that we want 3 columns, and then each column has a columnMinWidth attribute. The "3 columns" part implies the max value for children. The columnMinWidth value can then ensure that the content is easy to read, and be used for collapsing/stacking them when needed (for example using a columnMinWidth of 20em would be a reasonable value for text content)

[colorful-tones]

@jasmussen I'm trying to assimilate some of the justifications here, and I believe I'm 95% on board with intrinsic design, but I can not help but notice that your original CodePen's have display: grid;. Whereas, there currently is no use of display: grid in today's Gutenberg (WordPress). I'm not sure if this is a critical blocker for me, and I'm mostly just curious as to why display: grid is not used yet, and if there are considerations and concerns with incorporating it into more layout in Gutenberg?

I see there is discussion in #44557 but nothing in progress. 🤔

[jasmussen]

Grid can come to the editor, but it wouldn't be the preriquisite for intrinsic behaviors, nor even the only implementation thereof. I would think the "allow wrapping" feature built into the Row block, as well as fluid typography, are two existing examples of this. The width behaviors linked in this thread (#45364) represent another. It's also worth reiterating, that intrinsic behaviors do not preclude queries, it can all coexist.

One idea is for grid, when enabled, is to subsume content, wide, and full alignments. I've seen that working in a couple of older branches that explored it. But grid as applied across the whole editor (as opposed to just as part of a single block, such as how Row and Stack apply flex) comes with a couple of tradeoffs, including the breaking of margin collapsing. This isn't something we can't work with, the owl selector (* + *) for margins applied in most block themes mitigates this, but the grid still cascades and causes other challenges. And if it is to come with such tradeoffs, it means it should also bring with it more smarts than just subsuming alignments, e.g. resize handles and such. Which is to say: I think it's in the cards, but it requires the right idea. I'm not sure if that's a "Grid" block, but the way Row added flex properties has worked out rather well, IMO.

[cbirdsong]

A new option for gallery block seems like a good fit since it would allow more carefully art-directed sets of photos.

[colorful-tones]

comes with a couple of tradeoffs, including the breaking of margin collapsing. This isn't something we can't work with, the owl selector (* + *) for margins applied in most block themes mitigates this,

I totally forgot about this challenge and its implications in layout and how it could interact with the expectations of builders. Thanks for enlightening me.

I think it's in the cards, but it requires the right idea.

Heard. 👍

I'm not sure if that's a "Grid" block, but the way Row added flex properties has worked out rather well, IMO.

Yeah, Row block is coming along nicely. 🤘

[tomxygen]

While I really like intrinsic design, I think it solves 99% of situations, making responsive controls useless. However, there are still 1% of situations where having different designs on mobile and desktop is necessary.

Maybe classic responsive controls are not necessarily required, but I think that having the ability to show/hide elements based on viewport size is the bare minimum to achieve more complex designs.

Here is an example:
I'm trying to build the single product template with WooCommerce. On mobile, I want the product photo to be full width with no padding above, left, and right. It works great on small screens.
Instead, on desktop it should have padding all around it. Here's how it looks on both mobile and desktop:

To achieve that, I had to use the plugin Responsive Block Control plugin and have two different product photos, one showing on mobile and one on desktop.
This simple design is not achievable with core gutenberg.

In this issue I listed other use cases where responsive controls (at least show/hide based on viewport size is required): #50431

[strarsis]

CSS Container Queries are finally here (well supported in all relevant browsers)!
This would help so much with breakpoints with columns block, images, etc.

[aristath]

For the padding, you could use something like this: min(calc((100vw - 960px)*100), 20px) This will use a 20px padding for screens larger than 960px, otherwise it will be zero.
You don't have to use use responsive controls, most things are already possible with the existing controls - provided someone can write their own values for these things. Sure, it's not as straightforward as most people would want... But we should not rush into adding responsive controls for everything without first considering all the implications, the architecture etc.
The plugin you linked to looks fine, and Core doesn't necessarily need to include everything under the sun... It's fine to use plugins, that's what they're for!

at least show/hide based on viewport size is required

That is actually something that should be avoided at all costs if possible... Mobile and desktop should always have the same options and experience. It's not just about user-experience, it's also about accessibility. Showing different elements depending on the viewport is the worst-case scenario.

[tomxygen]

provided someone can write their own values

That's exactly the point.
Full site editing is especially great for those who can't write code and css, but if more complex design aren't achievable without writing css, many people will keep using pagebuilders like Elementor, or even consider other platforms like WebFlow.

Core doesn't necessarily need to include everything under the sun...

I'm not saying that core needs to include any possible option out there, however, any WordPress pagebuilder and any pagebuilder platform supports some kind of responsive controls.
By not implementing them in core, people who approach FSE for the first time will first be surprised that such a basic feature is not supported by Gutenberg, and then they will be annoyed because they will have to look for a third party plugin to enable it.

That is actually something that should be avoided at all costs if possible

I build landing pages for clients who often want to add many details, assets, long paragraphs etc.
It works fine on desktop, but not too well on smaller screens.
That's why I sometimes reduce the amount of content on mobile, and while it's very easy to do that on every pagebuilder software, it's not possible on Gutenberg.

[mtias]

@tomxygen absolutely, the intrinsic design principles are a useful lens to design the bulk of the features and layout tools in a sustainable way, but it doesn't capture everything you might want to do, like the ability to hide something on mobile or viceversa. The challenge is finding a way to introduce more specific responsive tools without drastically reducing the usability of the editor as a whole for the most common use cases. Most libraries that add breakpoint controls are adding them on per-property basis, which can easily result in people not knowing what is being applied or being overwhelmed by options.

There are plugin tools like "block visibility" that can bridge some of those gaps until we have the space and bandwidth to do something in core that can be sustainable. For example, one idea that has been discussed a few times is allowing edits done while viewing "mobile" to be applied to that breakpoint alone. The amount of edits you can do would be naturally limited to things that are expressive (for example, removing a block could become "hide this block" when in that context). It could be an option to explore.

[tomxygen]

allowing edits done while viewing "mobile" to be applied to that breakpoint alone

I really like this idea and I think it deserves further exploration.
It is definitely the most user friendly concept because what you're seeing is exactly what you're editing.
When I first met the site editor, I unconsciously apply edits to paddings of a group in the mobile view thinking that I was editing the mobile view only, and then found out that I messed up the entire page.

[tomxygen]

Hey @mtias

For example, one idea that has been discussed a few times is allowing edits done while viewing "mobile" to be applied to that breakpoint alone

Any chance you could link this discussion?

[mtias]

Yes, this issue captures the essence of it: #19909.

[tomxygen]

Thank you Matias.
I see this is a very important topic, and I've found a great article written by the developer of OllieWP that completely summarize what I think about the possibile implementation of responsive controls, which must not bloat the interface, and should be used for very specific instances only. He also added interesting mockups inside the article.

A native and iterative approach to responsive control in WordPress by OllieWP.
This is a very interesting mockup they built, which is also in the article:
VIDEO mockup: https://github.com/WordPress/gutenberg/assets/47855768/176d4000-6c3c-4988-9dfd-16dd5f0d3d7f

As many of us agree that, while intrinsic design is cool and works very well, responsive controls are sometimes needed for more advanced styling.
I've seen multiple times where people won't switch to full site editing until some kind of responsive controls are added.
For example, in the comments of this article on WPTavern:

Is there no push for more responsive controls? [...] (it) still keeps me away from Gutenberg.

Also, this is an interesting reading on Twitter.

I think that a first exploration of this issue may greatly improve Gutenberg ad a pagebuilder/interface.

[landwire]

Is there any effort to introduce responsive controls? Simple things as having text centred on small screens and left aligned on bigger screens is not possible at the moment. And that is just the tip of the iceberg, when you are working to a specific design for different screen sizes.

[Louis7777]

provided someone can write their own values

That's exactly the point. Full site editing is especially great for those who can't write code and css, but if more complex design aren't achievable without writing css, many people will keep using pagebuilders like Elementor, or even consider other platforms like WebFlow.

Core doesn't necessarily need to include everything under the sun...

I'm not saying that core needs to include any possible option out there, however, any WordPress pagebuilder and any pagebuilder platform supports some kind of responsive controls. By not implementing them in core, people who approach FSE for the first time will first be surprised that such a basic feature is not supported by Gutenberg, and then they will be annoyed because they will have to look for a third party plugin to enable it.

That is actually something that should be avoided at all costs if possible

I build landing pages for clients who often want to add many details, assets, long paragraphs etc. It works fine on desktop, but not too well on smaller screens. That's why I sometimes reduce the amount of content on mobile, and while it's very easy to do that on every pagebuilder software, it's not possible on Gutenberg.

I'll keep using Elementor or other software for page building, if Gutenberg doesn't offer Custom CSS per post (not just per block!). Also, yes, having to use third party plugins to gain responsive controls, is indeed annoying.