Add option to hide blocks based on screen size

[annezazu]

With the ability to hide blocks coming to 6.9, this issue is to discuss what comes next. Previously, adding the ability to hide a block based on screen size has come up as a requested feature and something to explore in this current issue:

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.

Hiding a block based on screen size has also come up in Responsive previewing and device-specific editing. To keep this in an actionable state, let's use this issue to discuss building upon hiding blocks for additional features in 7.0.

Development phases

Important

This feature will be iteratively developed behind an experimental flag to start with to minimize impact on the current editor UX.

These are high level so far. We have designs and the following proof of concept PRs as reference material:

• Add block visibility breakpoints support for dynamic configuration #73735
• Introduce responsive editing #73888

Phases and tasks for 7.0

Tasks are tracked on the WordPress 7.0 planning task.

Beyond 7.0

Speculative tasks for future releases.

• configurable breakpoints (in theme.json and eventually in the UI)
• extend visibility rules to other criteria, e.g., user roles or time. See Add option to hide blocks based on screen size #72502 (comment)
• centralization of breakpoint/device logic across WordPress packages (currently disparate)
• centralization of currently-hidden blocks somewhere the UI with toggle/reset controls
• extend style engine, where appropriate, to handle the display property and related logic

Related, and sorta related issues

• Adding class on preview (mobile, tablet, desktop, ...) to visual-editor or body #23430
• Allow responsive styles via theme.json #27107
• Allow extending editor preview in more ways #65005
• Replace hardcoded breakpoints in front-end CSS with more modular CSS #35848
• Responsive previewing and device-specific editing #19909
• Blocks: States #57719
• Hidden blocks should still be visible in the editor #73838

[bgardner]

I love the idea of hiding a block on mobile. It would allow me to remove a utility class in Powder:

https://github.com/bgardner/powder/blob/main/style.css#L165-L173

[ramonjd]

For me this raises a few of questions:

• where are the screen sizes defined. I'm assuming media queries - would these be user or theme.json defined? Or hardcoded, e.g., mobile/tablet/desktop as indicated in Responsive previewing and device-specific editing #19909
• what does screen size mean? window? container?
• would the block be rendered to the page (and hidden) or not rendered at all?
• assuming this applies to individual blocks or can it be applied globally, e.g., all cover blocks

[ramonjd]

Looking at specs and scope...

Based on what I've seen from the block visibility plugin, this task involves using the visibility block supports in conjunction with pre-defined breakpoints

Thanks to @jasmussen for the above image.

So it would work on a per-block basis initially I imagine, and probably add predefined classnames (?) for the editor.

Not yet sure about the frontend yet. Maybe extend the metadata as mentioned over in #71203 (comment)

	"metadata":{
		"visibility": [
            {
				"type": "breakpoint",
				"value": "var:preset|breakpoint|small",
			}
          ],
	}

And use that information to apply custom classnames linked to display: none/revert rules. Note that the plugin uses classnames like block-visibility-hide-large-screen block-visibility-hide-medium-screen block-visibility-hide-small-screen on the frontend. General question: how do we reduce the likelihood of conflicts here? Are namespaced classnames enough?

Anything we do should keep theme.json presets/settings in mind, e.g., users one day might define their own breakpoints.

One important question is:

Should each breakpoint work independently? If a user hides an element in tablet mode, should it only be hidden in that scope? For example @media (min-width: $break-mobile) and (max-width: $break-large) {?

I didn't look at the image above very closely :) checkboxes imply independently.

cc @ndiego for tips as well 😄

[ramonjd]

Ignore the design, labels and everything else on the follow video!!! 😄

My assumption is that the modal would appear when you click the existing "Hide/Show" context menu item, e.g.,

Kapture.2025-12-03.at.17.47.42.mp4

[jasmussen]

This is one of the features I'm the most excited for in the coming releases. I do still think that the modal as sketched out can potentially work here, but I would also love additional thoughts from @WordPress/gutenberg-design. Some thoughts in relation:

• When a block is hidden, regardless of breakpoint, there's a closed icon symbol in the list view. Let's make sure clicking that opens the same modal we'd show when hiding the block.
• It'd be nice to have a shortcut for the option. perhaps ⇧⌘H, or ⇧⌘/.

The main thing on my mind is how nice it is to be able to hide a block—just hide it with intent perhaps to come back to it later. Maybe I'm working on something, and want to keep part of the page a draft. The simple singular action as a boolean toggle has had tremendous value, I'm almost reluctant to encumbering it with more. Notably because hiding a block also omits it from the frontend markup. However responsive hiding would not omit it from the frontend. This is a key part of the flow we need to validate, first with best instincts, then with some PRs we can try as early as possible in the 7.0 phase.

My best instinct: it can work if we massage the verbiage. Here's an updated mockup:

Let me know if this resonates.

[ramonjd]

Thank you @jasmussen 🙇🏻 This is inordinately helpful

Notably because hiding a block also omits it from the frontend markup. However responsive hiding would not omit it from the frontend. This is a key part of the flow we need to validate, first with best instincts, then with some PRs we can try as early as possible in the 7.0 phase.

This is true. The block must still be rendered to the frontend for screensize-based rules to work.

Where I started was:

• we piggyback off the existing hide/show block support
• for simple hiding at all breakpoints, we don't render the block in the frontend at all. No point.
• for responsive, I think it's reasonable to assume that we must render the block and use CSS to hide/show, and it's reasonable to assume that users would accept this. How else do breakpoints work if not for CSS? 😄 I guess we could shimmy some JS in there, but... I don't think so.

It'd be nice to have a shortcut for the option. perhaps ⇧⌘H, or ⇧⌘/.
When a block is hidden, regardless of breakpoint, there's a closed icon symbol in the list view. Let's make sure clicking that opens the same modal we'd show when hiding the block.

Yes! I think I captured that in my VERY hacky POC PR. #73735

As for the shortcut, unless I broke something it should use the existing hide/show shortcuts (if they exist, I didn't test. If not, let's add them in)

[jasmussen]

Good thoughts, and it sounds right. The only reason I'm explicitly mentioning that we need to be clear about whether included in the markup or not, is that we want to avoid people accidentally leaking private information in the DOM without knowing. Which reminds me, with the above flow outlined:

• You press Hide block
• You get the modal with the "Hide from published document" checked by default, and can click apply
• You uncheck that and get the three breakpoint options

If at that point you go ahead and check all three breakpoint options, what happens then? Can we collapse those back and check the "Hide from published document"? Or what is the best approach there? I'm asking also to ensure the accessibility of not losing focus is captured.

Re: shortcut—cool! Let's also be sure the keyboard shortcut tip is shown in the menu, if that isn't already the case. Nice work!

[ramonjd]

If at that point you go ahead and check all three breakpoint options, what happens then? Can we collapse those back and check the "Hide from published document"? Or what is the best approach there? I'm asking also to ensure the accessibility of not losing focus is captured.

Yes! Collapse is an option. Here's the current state just as a FYI:

2025-12-08.18.05.59.mp4

[ramonjd]

Related issue (potentially to consider for a follow up)

• Hidden blocks should still be visible in the editor #73838

Only raising it as, with this feature, there are added variables and the user might wonder why blocks are appearing and disappearing, especially if they have not created the post themselves. cc @t-hamano