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. |
|
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:
SirLouen
left a comment
SirLouen
left a comment
There was a problem hiding this comment.
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.
This could benefit from the new BlockVisibilityInfo
| { visibilityNotice && ( | ||
| <Notice | ||
| status="warning" | ||
| isDismissible={ false } | ||
| className="block-editor-block-inspector__visibility-notice" | ||
| > | ||
| { visibilityNotice } | ||
| </Notice> | ||
| ) } |
There was a problem hiding this comment.
This could benefit from the new ../block-visibility/block-visibility-info BlockVisibilityInfo component introduced in #74180
There was a problem hiding this comment.
Nice, always a great idea to build it in smaller PR.
|
@youknowriad yes the feature was stabilised in #74839 and there's a core sync PR ready in WordPress/wordpress-develop#10629 |
|
I'm closing this then. Thanks |
|
Wait, should this actually have been closed? 74839 introduced responsive block visibility through the ellipsis > hide block menu, yes, but this PR introduces the ability to hide blocks through the preview dropdown. The latter is purely a gateway to breakpoint editing of any property: font size, line height, padding, colors, across those breakpoints. Essentially #19909. I'll let Matías reopen if that's the case, but that was always my understanding as far as the perspective. |
|
Ah I see, I wouldn't mind reopening but this is going to require a big rebase/merge |
|
As I understand it this was meant as a POC, not to be merged. For production-ready code it's better to iterate with small PRs progressively implementing features, allowing easier review and testing.
I think I understand the goal here, but as it stands the "view" dropdown only shows on desktop, so this would prevent anyone from doing responsive editing on a tablet or a phone. Though it's unlikely anyone will try to implement a desktop design on mobile, we should allow equal access to the feature at any screen size. It's also not clear whether this approach is better than just providing the controls to hide on whatever breakpoint, as the block visibility modal now does. Many folks don't use the "view" dropdown to resize their canvas, either because they don't know it's there or because resizing the window is easier. Perhaps some usability testing might help inform the way forward here? |
+1 That was my understanding too. Similar to #73735, this POC PR was incredibly helpful at the beginning for inspiration and direction, and to define the scope for a first iteration.
This feature will require greater planning and breakdown. We can come back to reference the ideas here for sure! 👍🏻 |
16 participants
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.