Introduce responsive editing #73888
Introduce responsive editing #73888
Conversation
Introduces the core infrastructure for responsive editing mode including toggleResponsiveEditing and isResponsiveEditing under an experimental flag.
Adds a toggle switch in the viewport preview dropdown to enable responsive editing mode. When enabled, the device icon shows with a purple indicator to signal editing is enabled.
Introduces new components for managing block visibility: - A few visibility utilities (isHiddenForViewport, etc.) - Shared hook for visibility state/actions - Visibility settings modal with device checkboxes - Toolbar indicator showing visibility status with device icons - Menu item for block settings dropdown (Hide/Show actions)
- Apply hidden class based on viewport visibility to block list - Add visibility notice to selected block inspector - Show Hide/Show menu item, hide Delete in responsive mode - Show visibility icons with device indicators for hidden blocks
- Uses Gutenberg style engine with rules_group for media queries - CSS is output via the block-supports context in the head
mtias
requested review from
ajitbohra,
ellatrix and
spacedmonkey
as code owners
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @lesley-pizza. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
github-actions
bot
added
the
First-time Contributor
mtias
removed
the
First-time Contributor
|
Forgot to show how list view looks: 
|
|
Size Change: +3.87 kB (+0.15%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 2e38185. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20105294258
|
|
Just looking at an existing POC to see what can be combined and what tasks we can record for follow ups/further development: At first glance, it looks to address most of what I was looking at and works in a very similar way. I estimate we're the same page about future follow ups too. There are only a few, minor differences. The device icons, and inspector bar hints are a great addition to reduce user forgetfulness or new user confusion as to why some blocks are disappearing. Like you've also noted, it was mentioned, and I may as well quote myself, that it'd be helpful to the user to have "a way for users to quickly locate them and toggle all hidden blocks on and off in one place, rather than have the user click around trying to remember which of their blocks they've hidden". Your PR has a slightly larger scope in some ways, e.g., "responsive editing mode" (related to #19909?) but reduced in others. In #73735, I was trying to honour the viewport width in conjunction with the preview toggler, which is more how the frontend would work. So in "Desktop", narrowing the window width would also trigger the breakpoints. Probably simpler to leave that out, and focus on the preview categories. Another architectural question for later that should help make the other pending tasks (I'm mainly thinking of configurable values in theme.json e.g., #27107) is that I think we need a single source of truth for both breakpoints AND device type selection. For example, by extending the How do you want to proceed? Happy to close my PR if you want to continue here. My idea was to use the POCs to list out a series of smaller, iterable tasks, e.g., set up PHP backend + unit tests, create responsive store + CSS in the editor, hook up with current block visibility etc. Cheers! |
|
Adding duplicate comments here as this seems relevant place for them as well. FWIW This is what we do in [Content Control](, add a floating icon indicator directly on the blocks with visiblity controls applied. I'd be all for an official way to add 
As for choosing them, sidebar inspector for us. Can be copied from block to block, disabled etc. 
Also we have global block rules in our pro version, so the idea of applying it to all blocks of a type is also possible. 
|
|
Gave this a test and found it works really well between the List view interaction, the snackbar notice, and the intuitiveness in the hiding/showing feature. Where it falls apart are in some of the smaller interactions. In particular:
Here's a quick view of me testing and running into some of this: testing.responsive.movI love the bones of this though! |
|
Exciting work, finally we touch this aspect, it's been a long time coming. There are a lot of little details to refine and polish (CC: @WordPress/gutenberg-design for awareness), but honestly as far as a basic interface for this, it's working surprisingly well for me. Here's a visual flow:
To be reductive about it: there's a screen size dropdown that allows you to apply a change to that breakpoint only. While there's much more nuance and details to hammer out, that's really the crux of the user experience, and commenting on just this, I'm into it. What it enables is specifically what has been outlined in older issues, that even if intrinsic reponsiveness carries its own benefits, there will always be a need for certain actions to apply only to certain breakpoints. I'd love for as many people as possible to test this PR and provide their feedback, so that what we can refine and land in 7.0 is the best possible default experience. Top of mind for me is solving the paradox of discoverability: in order to use these responsive tools and accurately preview each breakpoint, hidden blocks need to be actually hidden from the WYSIWYG canvas. At the same time, we are hearing a lot of feedback from users that once a block is hidden, it's—well—hard to find again. |
|
I think it should be just enabled by default that switch shouldnt be even needed it is not intuitive. |
|
Agree with Anne on the block toolbar interactions. Since the tools are only available when 'responsive editing' couldn't the eye icon just be a toggle button? That said... I also tend to agree with @sinanisler that the switch isn't super intuitive. Does this really need to be another mode? What if clicking the eye icon always opened a menu/modal, regardless of preview size: 
This could work the same way in List View too. |
|
Just wanted to link this back to some of the discovery work that was done in #57719 I still think that some of the ideas outlined there were good ones! Though I agree that some of the UI affordances like tying it into the responsive device dropdown are really nice in this approach here :) |
Yes, I think we should follow up on this as part of making the breakpoints also configurable instead of the hardcoded values we have now. @ramonjd in terms of moving forwards, I think we should probably put it inside an experiment because we'll need to do a few ongoing tweaks and a series of long running branches is going to be tough to manage. Redundancy in some of these interfaces seems important to make sure states are always clear. We can certainly introduce a panel for "visibility" that includes the viewport settings. We need to consider that "visibility" will expand to account for conditional rendering (like logged-in/logged-out), so a dropdown seems like it may become inadequate to provide the full context. The modal and sidebar panel seem better candidates there. Of course we can start more nimble and iterate there. @jameskoster I didn't push it on this branch because it was too much, but I have a working version were style attributes are also viewport-specific, and it becomes a lot easier to work with if you can just make style modifications across multiple blocks and they all get set together as part of the viewport. We can still (and I'd argue it's also necessary for clarity) show these icons or settings next to the tools they modify. But this will get super busy super fast. I wonder if that needs to be treated as part of the broad work on style inheritance / global / local clarity. |
|
Amazing! Can't wait for this. Quick question, will hiding on mobile prevent it from loading in the browser? Or does it load in under a css "display:none" tag? I ask because users were 100% use this to hide heavy file size items with the intention of serving something smaller on mobile. |
Oh nice, maybe you can use this: 
|
| } | ||
|
|
||
| // If all devices are hidden, return empty. | ||
| if ( count( $hidden_devices ) === 3 && |
There was a problem hiding this comment.
Ideally, we don't hardcode this. Maybe at some point we allow adding additional (or intentionally removing) allowed devices.
| if ( count( $hidden_devices ) === 3 && | |
| if ( count( $hidden_devices ) === count( $allowed_devices ) && |
There was a problem hiding this comment.
Then we'd make that filterable and adapt. For now it's a good way to ensure no extraneous info sneaks in.
|
|
||
| // If blockVisibility is an object, handle responsive visibility. | ||
| if ( is_array( $block_visibility ) ) { | ||
| $allowed_devices = array( 'desktop', 'tablet', 'mobile' ); |
There was a problem hiding this comment.
Should we allow filtering this list, together with the list of breakpoints?
| in_array( 'desktop', $hidden_devices, true ) && | ||
| in_array( 'tablet', $hidden_devices, true ) && | ||
| in_array( 'mobile', $hidden_devices, true ) |
There was a problem hiding this comment.
Why is this separate check needed? Isn't the count check enough?
| * @param array $styles Array of allowed CSS properties. | ||
| * @return array Modified array with 'display' added. | ||
| */ | ||
| function gutenberg_add_display_to_safe_style_css( $styles ) { |
There was a problem hiding this comment.
Nit: should $styles be called $attr instead (in sync with the filter naming and docs)?
There was a problem hiding this comment.
We might not need this at all since the style engine generates proper CSS rules, and enqueues them. In this case we're not using inline styles unless I'm missing something.
That said, I'm putting together a "backend" PR behind the experiment to kick this feature off. It'll take the best bits from both PRs.
There was a problem hiding this comment.
We might not need this at all since the style engine generates proper CSS rules, and enqueues them. In this case we're not using inline styles unless I'm missing something.
Ignore me.
My brain just reminded me that I wrote WP_Style_Engine_CSS_Declarations::filter_declaration and I forgot that it runs values through the filter. Such a long time ago...
There was a problem hiding this comment.
Yeah we need to add display to the list in safecss_filter_attr. I'm not sure why it's not in there yet, we output display styles for layout already. It might be those aren't going through the style engine at all.
| * @param array $styles Array of allowed CSS properties. | ||
| * @return array Modified array with 'display' added. |
There was a problem hiding this comment.
Should type be consistent with the filter type (string[])?
| const DEVICE_LABELS = { | ||
| Desktop: __( 'Desktop' ), | ||
| Tablet: __( 'Tablet' ), | ||
| Mobile: __( 'Mobile' ), | ||
| }; |
| ? sprintf( | ||
| // translators: 1: Device name, 2: The shortcut key to access the List View. | ||
| __( | ||
| 'Blocks hidden on %1$s. Access via List View (%2$s).' |
There was a problem hiding this comment.
| 'Blocks hidden on %1$s. Access via List View (%2$s).' | |
| 'Blocks hidden on %1$s. You can access them via List View (%2$s).' |
| : sprintf( | ||
| // translators: 1: Device name, 2: The shortcut key to access the List View. | ||
| __( | ||
| 'Block hidden on %1$s. Access via List View (%2$s).' |
There was a problem hiding this comment.
| 'Block hidden on %1$s. Access via List View (%2$s).' | |
| 'Block hidden on %1$s. You can access it via List View (%2$s).' |
| .getShortcutRepresentation( 'core/editor/toggle-list-view' ); | ||
|
|
||
| const noticeMessage = | ||
| clientIds.length > 1 |
| { ( { onClose } ) => ( | ||
| <> | ||
| <MenuGroup> | ||
| <MenuGroup label={ __( 'View' ) }> |
There was a problem hiding this comment.
This string needs a context; "View" can be a verb or a noun.
Yes, but I think we need to consider the option of creating more breakpoints as well and see how that scales. |
|
Thanks for working on this @mtias! Exited to test it soon! I like @jameskoster's idea of opening a menu when clicking the eye icon. I think @jasmussen's mockup would be the goal for the editor, but as long it's not possible to also change padding, text-alignment et cetera per viewport, I agree that this can be confusing to some users.
In that case I wonder how future proof names like |
|
How can I achieve the outcome described in this GitHub issue: #13363?
|
Good question. I'd speculate that these values would be default, and then one day overridable in theme.json. At some stage I think we'll be forced to introduce a single source of truth for both breakpoints AND device type selection. Various constants and lists of such things are scattered about the Gutenberg codebase like wedding confetti and it'll just lead to hangovers later. The |
|
This is a great start, and my initial testing works really well. However, I’ve noticed some confusing behaviour when using the Delete key in the list view with a Paragraph block while in Responsive Editing mode. When you first select a Paragraph block from the list view and press Delete, the block is removed as expected. But if you click it twice while in Responsive mode, the Paragraph block toggles the hidden attribute instead. I’m not sure if this is the intended behaviour or there is a valid reason for this but thought I would report it. This is in Firefox but also replicates the same way in Chrome... Firefox.mp4 |
|
Just to follow up on my previous comment, this is more of a question really. This feature introduces responsive editing, specifically for showing or hiding blocks, which appears to add a new class to the element: wp-block-visibility-{device}. My question is: is the intention to extend this approach to other attributes such as alignment, padding, or margin? Or is it solely intended for controlling block visibility between responsive breakpoints for 7.0? |
|
@eirichmond thanks for testing! This is indeed meant to expand to other block style attributes in the future, but the initial aim is just to account for block visibility to keep it manageable and narrow down the system and interactions. For example, I had it working with style attributes (both dimensions and font sizes) but it should be done step by step: Screen.Recording.2025-12-09.at.19.21.41.mov |
|
@mtias realised mp4 is incompatible, how about a .mov file... Firefox.mov |
This issue appears relevant. I believe it's something we're nudging at with extending metadata, and perhaps the Maybe that's what were you experimenting with anyway? 😄 Just wanted to note it. Cheers! |
|
To address the discoverability paradox, the simplest approach is to replicate the visual indicators already used in Live View directly within the canvas, reusing the same colour logic as the top toolbar. Regardless of which view the user is in, when Responsive Editing mode is active and a block is hidden for a specific breakpoint, the hidden icon should be visible along with its relevant device indicator. That device icon could also act as a control to switch the canvas to that view, giving the user a direct and intuitive way to unhide the block. The familiar purple used for synced patterns could also be reused as a subtle dividing line to clearly signal where a block is hidden. As previously suggested, floating device icons positioned near the block itself would make it immediately obvious where visibility rules are applied. Overall, the design rationale introduces subtle visual cues, such as muted thin lines and small icons, to improve discoverability without relying solely on the Block Inspector or the List View, which currently surface visibility states via notices and indicators. 
|
Great mockups @eirichmond! The issue with this approach is that it becomes tricky to represent correct block spacing and alignment. Imagine a stack with “space between”, containing an image, a paragraph, and a button. Now hide the button. Will the paragraph move down (as it should with space-between)? If it does, what should the distance be between the paragraph and the hide indicator? This is probably a bigger discussion, so we should move it to a dedicated issue. |
Fantastic discussion, thanks for sharing mockups, I just want to echo that. To elaborate a bit, and I believe this is an instinct Matías has shared as well: one of the things we can explore is similar to what has been added for notes. When you add a note to a block, a new "margin" shows up on the right, a clearance with space to show the note itself. This is a loose thought so far, but one thing we could do here is exactly the same: show a message: "Hidden paragraph", or "Hidden image". Click the message to show the block. Crucially this would maintain the WYSIWYG of the canvas itself. We need a visual to validate the idea, whether it is obnoxious or just right, and there's a balancing act in getting this right for responsive breakpoints. And there are some concerns with this idea, as well as other ideas for showing tokens in the main body. For example:
A visual for the pattern hiding feature: 
Perhaps the solution just is: if it's inside a pattern, we don't need to show blocks that are hidden, whether responsively or from the DOM. |
|
Let me actually visualize the notes idea: 
It's stretching a little bit the metaphor of what the Notes feature is for, but there's an argument that Notes is an editorial tool, as is the ability to hide blocks. I still think it important that if a block inside a pattern is hidden, responsively or otherwise, it does not need to get surfaced here, because the pattern is a curation mechanism. In fact, depending on how this feels, we might even show them in the Notes tray only, and have them indicated in the canvas only optionally: 
Something to figure out! |
tyxla
left a comment
tyxla
left a comment
There was a problem hiding this comment.
Played with this and I found one odd thing: if you enable Responsive editing and hide a block for Desktop, then disable Responsive editing:
- Should that block still be hidden for desktop?
- Should I be seeing this when wanting to show the block? I thought I just disabled Responsive editing:
WIP: Do not merge!
This pull request introduces a responsive editing mode to the block editor, allowing users to hide blocks on specific viewports (desktop, tablet, mobile). While it focuses on expanding the block visibility work, this editing mode is meant to be the seed to expand responsive editing to style attributes in general.
Closes #72502; See #19909.
When responsive editing is enabled via the preview dropdown, users can hide blocks on the current viewport using the block toolbar or ellipsis menu. Hidden blocks remain visible in the List View with visibility indicators showing which devices they're hidden on. The "Delete" action is replaced with "Hide" in responsive mode, emphasizing the contextual action. This also works for keyboard deletion and it renders a notice that the block was hidden.
Block Inspector
When a block is hidden on the current viewport, the block inspector displays a visibility notice at the top of the block inspector. This is also present when a block is hidden everywhere.
Responsive Toggle
The preview dropdown in the editor header includes a "Responsive editing" toggle. When enabled, the toggle activates responsive editing mode across the editor, indicated by a purple highlight on the device icon. This mode changes how visibility controls behave: the settings menu displays viewport-specific "Hide on [device]" / "Show on [device]" actions instead of opening the modal, and deleting a block hides it on the current viewport rather than removing it entirely. Users can switch between device previews while responsive editing is active to manage visibility across different viewports.
Visibility Modal
When responsive editing is not enabled, clicking "Hide" in the block settings menu opens a visibility modal. This modal provides granular control with checkboxes for hiding on desktop, tablet, and mobile individually, plus a "Hide everywhere" option (current behavior in 6.9) that removes the block from both the editor canvas and frontend entirely. The modal explains the difference: per-viewport hiding keeps the block in the published markup (for CSS-based responsive hiding), while "Hide everywhere" omits it completely. Both options note that hidden blocks can be accessed via List View. This may need more work on the copy.
Implementation Details
The feature introduces a
blockVisibilitymetadata attribute that stores visibility state per viewport. When set tofalse, the block is completely hidden (existing behavior). When set to an object like{ tablet: false, mobile: false }, the block is hidden only on those viewports via CSS media queries.On the frontend, the Style Engine generates responsive CSS using
rules_groupfor media query support. Had to add thedisplayproperty throughsafe_style_cssfilter otherwise the output would be filtered out. We should move this into the style engine itself. CSS is output in the document head via the block-supports context, with selectors combined per media query to minimize output.In the editor, visibility state is managed through a shared
useBlockVisibilityhook, with theisBlockHiddenselector made viewport-aware to show/hide blocks based on the current device preview.Pending tasks:
displayproperty in style engine logic, not ad hoc.