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

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

The following tasks will be moved to the WordPress 7.0 planning task eventually.

Phase 1: Backend Foundation

• Block visibility block supports: Define and document the blockVisibility attribute to support both boolean (hide everywhere) and object format (per-device visibility). Define breakpoints constants (mobile: <600px, tablet: 600-959px, desktop: 960px+) consistent with those in the editor.
• Frontend CSS output: Create PHP block support that generates CSS media queries using Style Engine and applies .wp-block-hidden-[device] classes to blocks based on their visibility settings. Modify WordPress safe_style_css filter to allow the display property so Style Engine can output display rules without filtering.
• PHP unit tests

Phase 2: Editor State Management Tasks

• Create visibility hooks and selectors: logic that manages all block visibility state, e.g., isHidden/isHiddenInAnyDevice selectors, hook for reading/writing block prop metadata (e.g., via updateBlockAttributes or in useBlockProps, handling single/multi-block selections. Add tests. This task comprises:
  • Making selectors/hooks device/viewport aware: check the current device preview mode against block visibility settings and return correct hidden state based on viewport.
  • Applying visibility classes: apply .wp-block-hidden-[device] classes and CSS rules in the editor so blocks hidden on the current viewport/device selection don't appear in the canvas.

Phase 3: Visibility UI Tasks

• Create Block Visibility Modal component: Build a modal component with checkboxes for Mobile/Tablet/Desktop visibility and a "Hide everywhere" option, including keyboard navigation and e2e tests.
  • Hook into existing block visibility controls in the block toolbar
  • Hook into existing block visibility controls in the block settings dropdown (list view and block) (⋮)
  • Ensure Visual Indicators are present and work, e.g., Show visibility icons in toolbar when block has visibility rules
  • Add block inspector visibility notices
  • Ensure the existing keyboard shortcut works as expected (Cmd/Ctrl+Shift+H)
  • Ensure hide/show command menu shortcuts open modal as expected
• Sync device preview dropdown with visibility: Ensure the device preview dropdown (Mobile/Tablet/Desktop) triggers visibility changes so blocks hidden on the selected viewport are immediately hidden in the editor canvas.
• Block inspector feedback and general discoverability: When a block is hidden or hidden on the current viewport, display a visibility notice at the top of the block inspector.
• Responsive Toggle: (TBD) The preview dropdown in the editor header includes a "Responsive editing" toggle. When enabled, the toggle activates responsive editing mode across the editor, and changes how visibility controls behave: the settings menu displays viewport-specific "Hide on [device]" / "Show on [device]" actions instead of opening the modal.

Phase 4: Documentation

• Documentation: describe blockVisibility metadata structure and breakpoint values, add examples for theme/plugin developers

Beyond

Speculative tasks for future releases.

• configurable breakpoints (in theme.json and eventually in the UI)
• 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

Further test scenarios

• undo/redo: are visibility changes undoable/redoable?
• Do blocks / patterns with visibility metadata insert correctly and work out of the box?
• Do reusable blocks with visibility rules save and work as expected?
• Keyboard-only navigation testing
• ARIA labels verification

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