Responsive previewing and device-specific editing

[jasmussen]

Work ongoing in #19082 (see also mockups) has enabled previewing responsive changes to existing blocks. Specifically, it enables previewing content at three breakpoints, mobile, tablet and desktop. This opens up a number of questions and possibilities, one of which is: can we leverage this responsive preview feature, to enable responsive editing?

Examples of responsive editing:

• Showing a drop-cap in a paragraph, only on the desktop breakpoint.
• Showing 1 column on mobile, 2 on tablet, 4 on desktop.
• Showing a block only on mobile, hiding it on tablet or desktop.

This ticket shows some initial mockups exploring what that might look like. These mockups assume the following design constraints:

• Responsive editing is an advanced feature that will be used occasionally, and most users likely won't use it at all.
• Responsive editing should work with every existing block, and not require any additional code or opt-in.
• Any responsive change should be instantly previewed, be direct manipulation.

The above constraints make this ticket an alternative approach to #13363.

Mockups

• Preview button is replaced with a dropdown indicating the view you're currently seeing. This happens only when an editor registers an editor-style, indicating that the editor itself is a preview.

• Dropdown contains three breakpoints, defaulting to Desktop.
• "Preview in new window" has the same effect as the classic button.
• "Device specific editing" is toggled off by default.

• When "Device specific editing" is enabled, any change you make is saved only for the current view.
• A centered label at the bottom indicates that any change you are making is for that breakpoint only. Clicking "Done" untoggles the button again.

• In the Phone breakpoint, content is previewed in a phone sized canvas, including any breakpoint changes

• In this shot, the Image block was deleted.
• The blue dot indicates a change was made.

• The blue dot has a tooltip on hover, and on click you can port changes to other breakpoints, or undo changes.

• The blue dot also appears for any post or page that has had responsive edits made. Click it to open a dialog to view or change those edits.

Next steps

For the time being, the above flow shows how to:

• Enable responsive editing.
• Preview mobile, and delete an image just for that breakpoint.
• Surface which elements were changed, and how to port those to other breakpoints.

This flow on its own should be portable to making any other changes, such as column changes, or even alignment or sidebar changes. So now is a good point to stop and revisit the ideas presented:

• Enabling responsive editing happening in the same dropdown that you use to preview the changes.
• The blue dot to indicate something was changed (often used for "unsaved changes" or "notification").
• The blue dot can afford a tooltip and interface for enabling at other breakpoints.
• A hidden block becomes a placeholder.

Pending your feedback, subsequent discussion points include:

• What does the interface that lists all responsive changes look like?
• What does a sidebar option with a responsive change look like?
• How well does the blue dot scale to other responsive edits?
  • What would it look like for a drop-cap change?
  • An alignment change?
  • A column change?

Let's discuss.

[epiqueras]

A simpler alternative for achieving the same sorts of layouts that this feature would power could be to have two grid blocks with different children that show/hide at different breakpoints.

I worry that scaling these "responsive edits" to all possible types of edits like alignment/color/sidebar settings could get complicated and confusing fast.

[karmatosed]

I really like the idea of this and my mind is skipping into how this would work for global styles. I keep thinking of the final step being confirming what you've changed - but that's to explore another time.

I really like the idea of the 'notification' indicator and this is a good spot (dot joke) to explore what that could be regarding color and shape.

[MichaelArestad]

I worry that scaling these "responsive edits" to all possible types of edits like alignment/color/sidebar settings could get complicated and confusing fast.

@epiqueras That is a concern I share, but as I think about the individual pages and posts I've created for clients over the years, I see flexibility in what settings change per device being valuable. I also predict that on any given page, there won't be as many device-specific edits as we might fear. I wouldn't expect more than a few images changing/showing/hiding, headlines changing in style or content (by showing/hiding), and maybe a modification or two to make something fit better on small devices.

Because of the potential mental overhead of learning how to make these changes and recognize them, I think this feels like a v2 feature. Something we can design and get ready to implement, but perhaps save it for a few months after folks get familiar with basic full site editing.

@jasmussen Right now, I'm digging the overall flow. Some thoughts in no particular order:

• I wonder how you could make the "deleted block" placeholder disappear so a user could get a more literal preview. In addition, is there a way to make it appear when needed?
• I wonder where the best place for the "device-specific editing" toggle is. It seems rather unexpected to me in that dropdown. Would it be a document-specific setting? An editor specific setting? Could it be something you prompt the user with as they edit something in a device preview view?
• I like the idea of dots, but wonder if we could show a letter or something to the same effect. For example, maybe a blue "D" (for device) or "R" (for responsive) might be good in its place and not be too reminiscent of the blue/red notification dot?

[epiqueras]

Can't grids achieve all of that as well? Without introducing something new to learn.

[ZebulanStanphill]

In the case of variable columns-per-row, you can accomplish that at the theme (or global styles) level using CSS Grid.

I'm also concerned about the blue dot. I think it should look more like an interactive element and use an icon of some sort.

Also, the "List device-specific changes" toggle should be split out into its own control on a separate line.

[jasmussen]

Can't grids achieve all of that as well? Without introducing something new to learn.

Can you elaborate on how grids can solve this? While CSS grid can change broad stroke layouts at different widths, these changes are layout-only. Unless I'm mistaken, you could not hide a block just on the mobile breakpoint, nor could you set a 50vh min-height on the Cover block just for the mobile breakpoint, and a 100vh min-height on the desktop.

Think of these mockups as looking at what the editor could be in 2 years. This is an exceptionally difficult interface, the way to build it is to start with the vision, then work our way towards that.

In 2 years full site editing will likely be in a better place, themes might be block editor aware, media queries work in the editor, blocks can leverage element queries, and the theme stylesheet is loaded into the canvas directly. (Probably.)

What does responsive editing look like in that interface? That's the question the mockups shown have tried to answer:

• By grouping responsive editing to the viewport width, everything remains direct manipulation. Instead of adjusting just the columns block for the mobile breakpoint, you'd adjust every block for the mobile breakpoint.
• By continuing to use smart defaults for blocks built (columns is born with 1 col mobile, 3 cols desktop) and keeping the responsive editing a power user feature that is off by default, you might never need to do this.
• But when you do enter responsive editing, the simple blue "something changed" dot will scale to any change made that is out of the ordinary, and provide an immediately visible interface for learning about, resetting, or adjusting those properties.

It's only when a specific breakpoint needs to be adjusted from what it comes with by default, that you'd need to enter responsive editing.

---

Inversely, if we were to keep going down the per-feature, per-block approach to responsive edits:

• You would lose the direct manipulation. You might be making edits to the tablet layout for a grid, while previewing at a desktop breakpoint. You might think you were also making tablet-only changes to content inside the grid, when in fact those changes are global.
• You would have no simple way to see a list of all responsive edits made to a page, or post, or template. You'd have to hunt through every block at every breakpoint to debug a change, which would be further confusing in case of blocks that come with smart defaults.
• You would essentially be white-listing every property and change that needed to have responsive edits, increasing the block API surface and putting the onus on block developers to decide which properties are surfaced as responsive.
• Specific to the dimension control, this is a sidebar-only interface, limiting the type of properties you can enable responsive edits for, and further distancing it from the direct manipulation interface of the block itself. This also means any feature not in the sidebar, would need another interface, actually another thing to learn.

Perhaps the biggest cost, in my mind, is the opportunity cost. We can't yet imagine what wonderful and crazy things users can build when everything becomes responsive-enabled.

---

The mockups shown here are early, in need of refinement. But they do adresss those challenges outlined directly. I would very much encourage additional ideas, but because this is a future thing, those ideas should address the same challenges:

1. Is there a way to make properties available to responsive edits, without requiring developers to add a dimension control on a per-block, per-feature basis?
2. How can we make responsive changes direct manipulation?

As an example of how why those two principles are worth tackling, I worked on this Layout Grid block, where we added responsive controls using a dimension control, like so:

This was created for lack of a better interface, and it's a bad user experience in many ways:

• It's not direct manipulation. If you choose a tablet breakpoint, only the layout grid block will show show the tablet layout, even though the rest of the page and even content inside, is shown at desktop dimensions.
• It does not work with either media queries or even element queries. If you resize the browser window, the tablet and mobile queries do not kick in.
• It's per-block, per-property, and not WYSIWYG. You might end up looking at a preview cobbled together by a tablet breakpoint grid, and a mobile breakpoint font size, because none of those properties are aware of the other.

[jasmussen]

I'm also concerned about the blue dot. I think it should look more like an interactive element and use an icon of some sort.

I tried using the classic multi-screen icon, but it added visual complexity and drew attention to itself in a way that was not conducive to the idea that you don't have to make responsive edits. The dot, on the other hand, felt like it immediately opened up the interface, and you've probably seen it many other contexts without even thinking about it:

In a way, the dot deserves better than to be called non-descript. It is an icon, and it means there's something here for you to look at if you want to.

[epiqueras]

Can you elaborate on how grids can solve this? While CSS grid can change broad stroke layouts at different widths, these changes are layout-only. Unless I'm mistaken, you could not hide a block just on the mobile breakpoint, nor could you set a 50vh min-height on the Cover block just for the mobile breakpoint, and a 100vh min-height on the desktop.

See this comment for how the grid should work: #19254 (comment).

You can hide a block on mobile by putting it in a grid that does so. And you can show different subgrids with different cover blocks to achieve that min-height difference.

What does responsive editing look like in that interface? That's the question the mockups shown have tried to answer:

The grid approach is also direct manipulation, can have sensible defaults and an immediately visible interface.

Inversely, if we were to keep going down the per-feature, per-block approach to responsive edits:

I wouldn't call it per-feature, per-block, it would just be limited to the grid.

You would lose the direct manipulation. You might be making edits to the tablet layout for a grid, while previewing at a desktop breakpoint. You might think you were also making tablet-only changes to content inside the grid, when in fact those changes are global.

You shouldn't be able to edit a grid at a breakpoint you're not previewing.

You would have no simple way to see a list of all responsive edits made to a page, or post, or template. You'd have to hunt through every block at every breakpoint to debug a change, which would be further confusing in case of blocks that come with smart defaults.

It would be simpler to see and display because the scope is limited to grid blocks. With the idea in this PR, any minor edit can be subject to the behavior.

You would essentially be white-listing every property and change that needed to have responsive edits, increasing the block API surface and putting the onus on block developers to decide which properties are surfaced as responsive.

Where did you see that proposed? I don't know how that relates to the grid approach.

Specific to the dimension control, this is a sidebar-only interface, limiting the type of properties you can enable responsive edits for, and further distancing it from the direct manipulation interface of the block itself. This also means any feature not in the sidebar, would need another interface, actually another thing to learn.

Yeah, I wouldn't suggest this either. I think we are talking about different things.

As an example of how why those two principles are worth tackling, I worked on this Layout Grid block, where we added responsive controls using a dimension control, like so:

Yeah, that is not ideal and probably why you rejected the grid idea.

You should not be able to edit a grid for a breakpoint you are not previewing. Furthermore, grid inner blocks should be the same between breakpoints. What you can set are two breakpoints for the grid: one at which it starts to render blocks in a list, one at which it starts to render blocks in a grid layout. Setting one of those breakpoints can change your preview to that size to see the change in action. Combining multiple grids that either hide, stack, or display typically at different breakpoints with different children can let you achieve any layout you can think of while maintaining all of the properties we want for the editor.

The problem with making all edits responsive is that we don't even have a definition for how an edit can be made or what they represent. They can be done programmatically by block developers; they can be done in an infinite number of different possible UIs. I can't even begin to think about how to surface all of them without ending up with some cluttered edited properties list that is hard to parse. Have you ever seen another editor that takes this approach? It might be helpful to see how others deal with it.

[shaunandrews]

• Love this. This viewport-specific editing mode will help us avoid having viewport-specific controls on a per-block level. I’ve already seen this done by a few plugins, and it leads to an overwhelming and repetitive UI.
• I think adding the switch to enable viewport-specific editing to the view menu makes a lot of sense. It exposes the functionality in context, and helps explain something I probably wouldn’t understand if it was presented elsewhere.
• I like the idea of showing a constant indicator when viewport-specific editing is enabled. You’ve done this by adding a line of text to the breadcrumb bar. But I’m wary of putting more into that bottom bar; People rarely notice it, and the breadcrumb list could get very long and break the alignment. Maybe this indicator should live in the top bar as a new element next to the view menu, or a variation of the view button itself. (I know, adding more to the top bar might be a bad idea.)
• Using the dot next to the device name in the menu seems a little strange. Its kind of mysterious. I wonder if using a label would be more clear. Something like “3 edits”.
• Visually, I find the hidden block to be too strong. But that’s minor. Conceptually, I don’t love that the block still displays something and takes up space in the canvas when hidden. I wonder if there could be a way to completely remove it, and add a button somewhere saying “show 2 hidden blocks”. This way I could toggle them on or off depending on what I’m doing. Otherwise, I worry that hidden blocks will break the layout in the editor and break the WYSIWYG promise of the canvas.

[jasmussen]

You’ve done this by adding a line of text to the breadcrumb bar. But I’m wary of putting more into that bottom bar; People rarely notice it, and the breadcrumb list could get very long and break the alignment. Maybe this indicator should live in the top bar as a new element next to the view menu, or a variation of the view button itself. (I know, adding more to the top bar might be a bad idea.)

✨

Great observation. There might even be an opportunity here to unify what pattern we come up with, with the Code Editor which currently has an "Exit" bar at the top.

Using the dot next to the device name in the menu seems a little strange. Its kind of mysterious. I wonder if using a label would be more clear. Something like “3 edits”.

Good idea to explore. It's a little space constrained, but it seems like it should be doable?

Visually, I find the hidden block to be too strong. But that’s minor. Conceptually, I don’t love that the block still displays something and takes up space in the canvas when hidden.

Good thought. This comment surfaces a challenge I had not considered, the case where the hidden block should not affect the layout, which a placeholder like this would do. Imagine hiding the 3rd menu item in the navigation block just on mobile.

I wonder if there could be a way to completely remove it, and add a button somewhere saying “show 2 hidden blocks”

This seems very much worth sketching out, because with your point very well made, the challenge becomes creating an obvious interface for unhiding those blocks when you need to.

Thanks all for the feedback, and keep it coming. The feature outlined here is a ways out, so let's keep the ticket open to additional input.

[johnstonphilip]

Related: #20244

[paaljoachim]

This is a big issue.
Should we break this issue into more actionable issues (or a test PR)? As it will create an easier focus on smaller features.
As we need to figure out an easier way to get movement here.

[jasmussen]

A block I'm working on, Layout Grid, will change the viewport when you select a responsive option in the sidebar — incoming feature. Testing the experience on that plugin sheds quite a bit of light on the various bit and bobs we can consider here.

[danielbachhuber]

From Row Block: Add support for centering the middle item when the left and right are unequal:

<!-- wp:group {"align":"wide","layout":{"type":"flex","flexWrap":"nowrap","justifyContent":"space-between"}} -->
<div class="wp-block-group alignwide"><!-- wp:paragraph {"style":{"typography":{"textTransform":"uppercase"},"layout":{"selfStretch":"fixed","flexSize":"33%"}},"textColor":"custom-color-1"} -->
<p class="has-custom-color-1-color has-text-color" style="text-transform:uppercase">Technology Leadership</p>
<!-- /wp:paragraph -->

<!-- wp:site-title {"textAlign":"center","style":{"elements":{"link":{"color":{"text":"#36506c"}}},"typography":{"fontSize":"3rem","fontStyle":"italic","fontWeight":"700"}}} /-->

<!-- wp:paragraph {"align":"right","style":{"typography":{"textTransform":"uppercase"},"layout":{"selfStretch":"fixed","flexSize":"33%"}},"textColor":"custom-color-1"} -->
<p class="has-text-align-right has-custom-color-1-color has-text-color" style="text-transform:uppercase">Tualatin, Ore.</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

Things are a bit squashed on mobile:

It doesn't look like it's possible to conditionally hide those on mobile, though?

It would be helpful to be able to show/hide blocks based on viewport width 😁

[tomxygen]

After more than three years, unfortunately this issue hasn't been tackled yet.
In my experience, and based on what I read online, this is the most important (missing) feature that prevents people from switching to FSE from other page builders.

It's fine if I'm designing a website for myself and I know the limits and constrains of FSE, but it's not if I'm designing a website for a client. I can't just tell them that WordPress is not ready for their header alignment on mobile.

I think that the proposed mockup works great and it's easy to understand.

While intrinsic design takes care of almost any design difference from desktop to mobile, it's not always what the client wants, and designers do need it.
This is especially important because ALL other page builders and most importantly ALL other competing platforms to have them.

[hgeist2]

I feel like Gutenberg is doomed. I am sorry, i did not work on the wordpress core so far, so its easy to complain. Thx for all the hard work in advance.

That said, i think its horrible, how the answer to every proposal around device specific controls is "have a better design philosophy". What kind of clients do you work for? Their websites must be ridiculously small and they must be super nice.

I have clients that just want things to work in a certain way and i need these controls for it. Also browsers like safari for ipad, iphone have specific quirks that make it impossible to use some of the very advanced css for now.

A medium sized companies website feels like a big hack. I need a theme, i am forced to use some part of their block bundle and another one, because gutenberg is way too simple. And then i wrote 6000 lines of scss. What the hell man?

Apart from speed problems, because react is horribly slow (should be rebuilt with svelte), the lack of advanced, breakpoint specific controls is the main issue with Gutenberg.

Do you know which users are most important in the decision making / for approving PRs related to this?

[landwire]

It's now almost 4 years since this issue has been opened. It would be great to get some traction on it. I really want to use Gutenberg in a professional context and so much stuff is really coming along nicely, but the lack of responsive controls is a really big problem for some designs that I am confronted with.

[paaljoachim]

Check out the exploration here:
States. It touches upon multiple areas including responsive editing.
#57719

[grantgeard]

I think all the ideas and explorations presented over the years look great and the majority of theme developers would probably be happy with any of them being implemented as a start. There have been lots of well thought out options for breakpoints and styles in theme.json, new controls in the Block Editor, and combinations of the two.

That being said, the ideas being proposed today don't feel drastically different from the ones that were proposed 4 years ago. I don't think there are any new ideas left to explore after 4 years and I don't think anyone wants to spend another 4 years talking about where the ideal place to stick the dropdown for desktop/tablet/mobile is.

If this is the direction the Block Editor is going, someone just needs to make a decision.

[paaljoachim]

There is a lot of movement around grids and that can also impact device specific editing.
Improvements to Grid Layout and Subgrid support
#57478

[SaxonF]

A suggestion on how to possibly move this forward in an iterative manner.

The idea behind the States issue was to build a flexible approach to define the multitude of ways a particular pattern/block can be displayed depending on its state. That may be due interactivity like button hover, container width, or a user defined state that can be transitioned to. The proposal covers responsiveness by treating container width as a type of state.

So the suggestion is that we start with patterns. When creating or editing a pattern in isolation, you can switch container widths (which you can currently do via preview dropdown), and any styles added within that width are applied from that width downwards. This makes use of container queries not viewport. It would also make use of the style inheritance work to highlight changes that are applied to a specific width.

We want to encourage an intrinsic first approach to responsive design, but there will always be scenarios where adjustments are needed, particularly on more complicated sites that may exist in the enterprise space. I believe starting with patterns and container queries does not diverge from this principle. It also means patterns can be shared across themes with responsiveness built in. We can then move towards viewport level styles if it makes sense, but I imagine that introduces greater technical challenges.

I would like to know the level effort to required to implement this starting point making the assumption we aren't touching any UI and just making use of the preview dropdown. It's worth doing a little tech spike into effort to better understand where this work might sit amidst all the other priorities.

[jarekmorawski]

When creating or editing a pattern in isolation, you can switch container widths (which you can currently do via preview dropdown), and any styles added within that width are applied from that width downwards.

This is aligned with how theme designers I met imagine mobile-specific changes working. The UI changes when one switches from desktop to tablet and mobile, which is enough of an indication that the user is now in a different editing mode.
Going this route would simplify state management and block visibility—if a block is removed in the mobile view, it will still be visible on tablet or desktop.

To compliment this flow, we'd likely need some kind of control to let the user restore the default desktop layout in case they want to go back or make changes. In such case, we'd treat the desktop layout as the source of truth, which makes sense it's the default view that fills up the canvas when the user first enters the editor.

[afmarchetti]

I believe that mobile responsive options are essential. For instance, if a user wants a paragraph to be left-aligned on desktop and center-aligned on mobile (to improve mobile UX), it is currently not possible. If we want WordPress to stay ahead, this kind of attention to detail is crucial. Implementing these options will boost the adoption of new FSE themes. @mtias

[tomtev]

We have done some exploration with this.
It's just a small indicator that shows if the style option can have responsive value when previewing mobile & tablet.

Screen.Recording.2024-11-05.at.23.40.31.mov

[mtias]

@tomtev thanks for the reference!

A few things that are left unspecified:

• What is the "default" — assuming it's desktop, it wouldn't be ergonomic to do "mobile first" design.
• How customizable are breakpoints (UI, theme config, etc).