An iteration/scope issue for hiding/showing blocks based on screen size in WordPress 7.0.

Scope

Building upon:

• Add option to hide blocks #50756

Phase 1: Backend Foundation

• Block visibility based on screen size: add backend block support #73994
• Block visibility supports: refactor metadata to use nested structure #74602
• Block visibility: render blocks when hidden at all viewports (and other changes) #74679

Phase 2: Editor State Management Tasks

• Block visibility based on screen size: basic clientside state #74025
• Block visibility based on screen size: add rules to hide on viewport size #74379

Phase 3: Visibility UI Tasks

• Block visibility: add viewport modal and controls UI #74249
• Block visibility: add visibility notice for hidden blocks in the block inspector #74180
• Block visibility: create selectors for block visibility in current viewport (device setting or responsive) #74517
• Block Visibility: Show keyboard shortcut in context menu #75334
• Check copy in general, e.g., should be “Hide blocks” and “Show blocks” when multi-selecting; should that be “Block visibility settings updated” for success notice since you still need to save the doc...
• Block Visibility: Centralize modal state in block-editor store #75367 Render the modal so that it's accessible from command center. See discussion Block visibility: add viewport modal and controls UI #74249 (comment)
• Block Visibility: Show viewport tooltip in list view for hidden blocks #75404
• Block Visibility: Simplify toolbar for hidden blocks #75335
• Block Visibility: Disable Apply button on non-dirty state #75494
• Block Visibility: Disable visibility toggle for children of sections #75447 Remove block visibility show/hide options (mainly shortcut?) from blocks in content only mode/pattern editing. See comment: Block Visibility: Centralize modal state in block-editor store #75367 (review)

Phase 4: Documentation and bug fixes

• useBlockVisibility: consolidate useMemo calls to the output object #75120
• (dev note) describe blockVisibility metadata structure and breakpoint values, add examples for theme/plugin developers and also how to disable it via filters.

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

Not in scope (7.0 and beyond)

• Look into the toolbar "show" icon and whether it could be shortcut to showing the block without the modal, see discussion at Block Visibility: Simplify toolbar for hidden blocks #75335 (review)
• In the list view, somehow indicate that blocks are hidden by virtue of their parents' visibility settings, e.g., icon or opacity?
• Convert block visibility JS files and constants to TS. See useBlockVisibility: consolidate useMemo calls to the output object #75120 (comment) and Block visibility based on screen size: add rules to hide on viewport size #74379 (comment)
• Configurable breakpoints (in theme.json and eventually in the UI)
• theme.json settings configuration at sitewide and block level to disable the feature in the UI (like other block supports)
• 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

Original issue

• Add option to hide blocks based on screen size #72502

Explorations

• Add block visibility breakpoints support for dynamic configuration #73735
• Introduce responsive editing #73888
• Enhance Block Visibility: Introduce 'Show Hidden Blocks as Ghost' fea… #74150