Add block visibility breakpoints support for dynamic configuration #73735
Conversation
|
Size Change: +8.51 kB (+0.33%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
docs/contributors/code/block-visibility-breakpoints-extensibility.md
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/block-visibility-breakpoints/modal-manager.js
Outdated
Show resolved
Hide resolved
| checked={ hideEverywhere } | ||
| onChange={ handleHideEverywhereChange } | ||
| /> | ||
| <div className="block-editor-block-visibility-breakpoints-modal__breakpoints"> |
There was a problem hiding this comment.
Lots of potential for visual/structural improvements here, e.g., using Stack components. Spacing is a bit weird.
| @media (max-width: 599px) { | ||
| .wp-block-hidden-mobile { | ||
| display: none !important; | ||
| } | ||
| } | ||
| @media (min-width: 600px) and (max-width: 959px) { | ||
| .wp-block-hidden-tablet { | ||
| display: none !important; | ||
| } | ||
| } | ||
| @media (min-width: 960px) { | ||
| .wp-block-hidden-desktop { | ||
| display: none !important; | ||
| } | ||
| } | ||
| '; |
There was a problem hiding this comment.
Breakpoint values exist in a few places:
- https://github.com/WordPress/gutenberg/blob/651badeaea8b4b1fb046868485e9d8c3993a5fdf/packages/components/src/utils/breakpoint-values.js
- https://github.com/WordPress/gutenberg/blob/651badeaea8b4b1fb046868485e9d8c3993a5fdf/packages/base-styles/_breakpoints.scss
- https://github.com/WordPress/gutenberg/blob/651badeaea8b4b1fb046868485e9d8c3993a5fdf/packages/compose/src/hooks/use-viewport-match/index.js
ramonjd
added
[Feature] Blocks
| } | ||
| ``` | ||
|
|
||
| This structure assumes exactly three semantic breakpoint ranges and doesn't support arbitrary breakpoint names. |
There was a problem hiding this comment.
Thought: if we were to consider supporting an arbitrary number of breakpoints to be defined with custom names, what might the editor UI to view different breakpoints evolve into?
There was a problem hiding this comment.
True. Assuming we do allow n presets like we do with font sizes etc, they solve that using select boxes for items greater than x.
There was a problem hiding this comment.
Or we could just move to resize handles everywhere instead of these fixed options 😄
There was a problem hiding this comment.
Or we could just move to resize handles everywhere instead of these fixed options
Yeah, the hard-coded values seem pretty prescriptive. I reckon a lot of these types of issues will crawl out of their respective holes and demand solutions if Core ever lets folks add custom breakpoints.
There was a problem hiding this comment.
Thought: if we were to consider supporting an arbitrary number of breakpoints to be defined with custom names, what might the editor UI to view different breakpoints evolve into?
This is not a direct answer, but contains some tangential thoughts that affect this interface:
- The Preview UI showing a desktop icon is not intuitive, if you want to preview in a new tab, it's not where you'd look.
- With collaborative and block comments underway, eventually we'll likely need a closer-to-industry-standard dropdown UI for things like "Suggesting".
- The button to "view the published post" that only appears if a post is published, honestly that button is useful all the time.
- There's a LOT of buttons in the top toolbar, even more when there are extension sidebars. Aside general cleanup and careful consideration, we should look at spacing density to optimize the space.
- The document title blob is useful to see what you're editing, but it's not intuitive as far as isolated editing navigation where I'd expect breadcrumbs, and honestly I'd expect to be able to change the title, or perhaps do post actions like delete, duplicat, by engaging with this control. Instead it just opens the command palette, which has a different invokation affordance inside the editor vs. outside.
- And finally, breakpoint editing, and major responsive tools are missing. The fact that we show desktop/mobile/tablet as purely preview tools, is a little misleading. In fact the resize handles you see on patterns being edited in isolation, is a more ergonomic tool for this.
All of that is me saying, the top toolbar deserves a vision and some near term steps towards it. I could see "Preview in new tab" and "View post" in a menu that also contained mode switches like Edit, Suggest, Preview. Where that surfaces clearer responsive tools needs some careful thought, but the benefit of each of those modes is each of them are context switches that can surface contextual tools.
ramonjd
force-pushed
the
try/hide-blocks-breakpoints
branch
from
37d5e42 to
8817370
Compare
|
Flaky tests detected in f31c36c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20050314541
|
…oolbar integration, and enhance modal functionality with improved breakpoint handling.
…he existence of breakpoints before processing. Update paragraph block example to include a complete content attribute for better clarity.
… states are only checked if all blocks share the same values. Update logic to handle empty block arrays and improve initial state calculations for breakpoints and "Hide everywhere" option.
…and breakpoint visibility. A block is now considered hidden if it is set to be hidden everywhere or if it has any visibility settings for mobile, tablet, or desktop breakpoints.
…ality Introduce constants for block visibility breakpoints to streamline the handling of responsive visibility settings. Update the block visibility breakpoints modal to utilize these constants, improving clarity and maintainability. Enhance error handling and ensure consistent state management across the modal and toolbar components.
…ity logic. The `block-visibility-breakpoints.php` file has been deleted, and its functionality has been integrated into `block-visibility.php`, which now handles both "hide everywhere" and responsive breakpoint visibility. This streamlines the code and improves maintainability.
… duplication and improving code organization.
…oint visibility. Introduced a new test suite for validating block visibility behavior across various scenarios, ensuring accurate handling of visibility classes based on defined breakpoints.
… directly into menu items and toolbars. Removed the modal manager and slot system, simplifying state management for visibility breakpoints. Enhanced user interaction by allowing modals to open directly from toolbar buttons and menu items.
…ndling. Changed the label from 'Hide everywhere' to 'Hide from published document' for clarity. Added z-index styling to ensure proper layering of the modal over other components.
… eliminates outdated content regarding hardcoded breakpoints and extensibility considerations, streamlining the documentation for block visibility features.
…es. Combined multiple selectors for hidden blocks under flex layout into a single declaration for improved readability and maintainability.
…tate, ensuring it remains in the toolbar if previously shown, even when no visibility is set. Updated component documentation for clarity on rendering conditions.
…d notifications for hidden blocks and saved visibility settings, utilizing keyboard shortcuts for improved user feedback.
tellthemachines
left a comment
tellthemachines
left a comment
There was a problem hiding this comment.
Quick note that breakpoint visibility isn't working in the editor; I tried hiding a block only on mobile and it disappeared altogether for all breakpoints.
It's working fine on the front end though.
The other thing I'm curious about is why we went with
visibility: hidden;
overflow: hidden;
height: 0;
border: none !important;
padding: 0 !important;
for hiding blocks in the editor instead of just display: none? I understand that choice was made when we added the option to hide blocks regardless of breakpoint.
Yeah, lots to do still on this WIP branch. I'll take a look, thanks!
Is the answer in the comment above the style? // Hidden blocks.
// In order for the block toolbar to render correctly, blocks cannot be hidden.
// Instead, use styles to visually hide blocks. |
…nd functionality. Consolidated visibility settings retrieval and updated class application for hidden blocks based on overall visibility state.
I think I fixed that bug, but there's another issue that needs to be sorted as well. I think a user would expect the preview dropdown to work and trigger the hide/shows, however those options manipulate the iframe width. Conveniently the values used for mobile/tablet/etc are different for the preview drop down. Here are the use viewport match ones. So somehow we need to know which device the user has selected, but it's in the editor package, which can't be used in the block-editor package 🤔 Might need some abstraction work down first. Not sure. |
… conditions. Now only checks if blockVisibility is false, as breakpoint visibility is managed via CSS classes.
ramonjd
force-pushed
the
try/hide-blocks-breakpoints
branch
from
6ceb1b4 to
386c102
Compare
…. Added explanatory text for hidden blocks based on visibility settings, improving user guidance on block management in the editor.
… any breakpoint visibility set.
I think it is possibly to avoid the block toolbar disappearing when the flow is select block > click block toolbar kebab menu > click "hide block". I think "display: none;" might cause a focus loss in that case. That doesn't make it invalid, I think display none is the correct thing to do, actually remove it from the DOM. Right now it's a bit weird if you have paragraph | hidden block | paragraph, and arrow key from the 2nd paragraph towards the first, it will actually pass by the hidden block still there, on its way to the first block. My instinct for the first versions would be to require use of the list view. |
- Introduced `deviceTypeKey` to manage device type settings in block editor. - Updated `usePreviewBreakpoint` hook to override viewport detection based on device type (Mobile, Tablet, Desktop). - Enhanced `useBlockEditorSettings` to retrieve and utilize device type for improved block visibility management.
The latest update does this, albeit by adding another setting to the block settings. Kapture.2025-12-10.at.21.28.58.mp4Having gone through some past issues calling for breakpoint previewing, device preview extensions, theme.json breakpoint definitions, even block states, I'm wondering if I should create an issue proposing a single source of truth for both breakpoints AND device type selection. For example, by extending the Breakpoint logic is duplicated across 3+ packages. Currently, device type selection (Desktop/Tablet/Mobile) is managed by |
| remove_filter( 'render_block', 'wp_render_block_visibility_support' ); | ||
| } | ||
| add_filter( 'render_block', 'gutenberg_render_block_visibility_support', 10, 2 ); | ||
| add_action( 'wp_enqueue_scripts', 'gutenberg_enqueue_block_visibility_breakpoints_styles' ); |
There was a problem hiding this comment.
This would use the style engine enqueuing system eventually, just a shortcut for now
|
Looks good at a glance. What happens if you deselect the block after hiding it? That's the most complex aspect to ensure a good behavior for. |
On this branch (and the other POC branch #73888) this: Kapture.2025-12-12.at.10.22.59.mp4Is that what you mean? 🤔 I kinda empathize with the "dimmed" out hidden block viewport here, if only to indicate that something has happened on the canvas. Even if it's dimmed, then fades out. We can't rely on the list view or inspector being open. Maybe it's a matter of being cleverer with the notices 🤷🏻 |
|
Yep, empathise is a good way to describe what is a valid issue. What's crucial for me is we seek a solution that does not break WYSIWYG. I need to marinate more on this, but one loose idea do someting similar to what block notes does. When a document has notes, they are showin in the margin on the right, with a bubble. We can do something similar: “There's a block hidden here", and when the note is selected, so is the hidden block. The main challenge here is that this reserved margin is only available, for the moment, when "Show template" is toggled off. Ideally that margin would be available everywhere. |
|
Noting that I just tested this and if I hide a block everywhere then hit "show" it kept showing me the same "hide" prompt: bug.with.hiding.mp4I have to de-select hide everywhere for it to then "show". Not sure if that's the best UX if someone is explicitly selecting "show". Perhaps in this case, we shouldn't show the collapsed "hide all" and instead show the granular options for editing where to show. |
That could be me misinterpreting the designs over at #72502 (comment) But anyway, all this is good to know, @annezazu Thanks for testing! This PR and the other POC PR won't be the final product I reckon, but it's great to get feedback to guide development. I've begun splitting up the PRs already to make it easier to get the groundwork in iteratively, and also ease code reviews. I've listed them on #72502 |
Thanks for recording a video, @annezazu, I've been around the block on some other tasks, so I haven't been able to follow this with super precision. Aspects of what Ramon has built are super intentional insofar as it feels critical to me to make clear to the user that hidden content is omitted from the document, but responsively hidden content is not. The latter "leaks", it's still included on the frontend. It feels so important to get this just right, so you don't hide something thinking it's private but actually it's just The precise flow for getting that right we'll need to figure out, thank you Ramon for the PR so we can do just that. Let me just recount the precise details of the motivation for the current path, and then some other options. The present idea is this:
So what is the motivation for adding all these steps? It is to:
An alternative which we discussed, in a chat, I think, is to use a radio group instead. Here's an ASCII mockup of what that could look like: And when toggled to breakpoints: The radio might be simpler for capturing the same motivations. On a final note, there's still the "visibility" paradox, for which this idea is new. |
Important
This is an experimental PR for illustrative purposes only. If the approach is sound, it'll be broken up into smaller PRs for review and refactor.
Mostly vibe coded to demonstrate a flow for #72502
TODO
useViewPortisn't looking at the iframe width, but the parent window. So somehow we need to know which device the user has selected, but it's in the editor package, which can't be used in the block-editor package 🤔 Also very conveniently the values for mobile/tablet/etc are unique in the drop down. Look at the use viewport match ones.2025-12-08.18.05.59.mp4
What?
Closes
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast