Block visibility based on screen size: basic clientside state #74025
Conversation
ramonjd
changed the title
|
Size Change: +179 B (+0.01%) Total Size: 2.6 MB
ℹ️ View Unchanged
|
ramonjd
added
[Type] Enhancement
|
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: @ezequiel142atrabajo-boop. 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. |
ramonjd
changed the title
| renderingMode, | ||
| editMediaEntity, | ||
| wrappedOnNavigateToEntityRecord, | ||
| deviceType, |
There was a problem hiding this comment.
I left out responsive Editing mode for now. Thinking that feature could be its own PR.
There was a problem hiding this comment.
Pull request overview
This PR implements client-side state management for block visibility based on device preview mode. Blocks with visibility restrictions are now hidden in the editor when the active device preview matches their visibility settings.
- Added viewport-aware selectors (
isBlockHidden,isHiddenInAnyDevice,getBlockVisibilitySettings) - Created utility functions for checking and toggling block visibility across viewports
- Implemented
useBlockVisibilityhook for managing visibility state and actions - Passed device type from editor settings to block editor for viewport-aware behavior
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
packages/editor/src/components/provider/use-block-editor-settings.js |
Added deviceType from editor store to block editor settings when experiment is enabled |
packages/block-editor/src/store/private-selectors.js |
Updated isBlockHidden to be viewport-aware; added isHiddenInAnyDevice and getBlockVisibilitySettings selectors |
packages/block-editor/src/hooks/use-block-visibility.js |
New hook providing visibility state and update/toggle actions for blocks |
packages/block-editor/src/hooks/block-visibility-utils.js |
New utility functions for viewport visibility checks and toggling logic |
packages/block-editor/src/components/block-list/block.js |
Moved isBlockHidden selector call to make it available in preview mode |
packages/block-editor/src/hooks/index.js |
Exported useBlockVisibility hook |
packages/block-editor/src/store/test/private-selectors.js |
Added comprehensive tests for new selectors |
packages/block-editor/src/hooks/test/use-block-visibility.js |
Added tests for useBlockVisibility hook |
packages/block-editor/src/hooks/test/block-visibility-utils.js |
Added tests for visibility utility functions |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Flaky tests detected in a635b60. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20289541479
|
|
I'm not sure we should be conditionally rendering blocks depending on the current viewport type. The problem is that, if you have built a page that has certain things hidden on mobile and then you try to edit it from an actual mobile device, you won't get the correct view of it: 
It would be simpler if the "hide on..." just added a classname to the block in the editor and we let the media queries do their work. |
Good point. And it matches the existing show/hide method. That's what I was doing over in #73735. I'll look at that, thanks!
Do you mean if we hide/show according to the viewport size? If so, I think this comment is related: #72502 (comment)
And related follow up: #72502 (comment) Where I wanted to take it was hide/show only based on the dropdown preview value, not the window size. The flaw here is "desktop" since that's the default. There's some chatter about how to represent hidden blocks, e.g., dim them. What's your preference, or is there an alternative? |
And if we extend to theme.json later, we can generate these classnames + rules on the backend and add to global styles CSS. 👍🏻 |
ramonjd
changed the title
| border: none !important; | ||
| padding: 0 !important; | ||
| opacity: 0; | ||
| margin: 0 !important; |
There was a problem hiding this comment.
Prevents a "jump" in some blocks when selecting via list view.
Actually, I've left it for now because of the existing block visibility supports, which doesn't render the block. I think that's on purpose. cc @t-hamano for fact check. On the plus side, I've simplified this PR greatly to do only one thing: apply the I deleted things that can be done later, or are redundant. |
The "View" dropdown will never allow us to preview a viewport bigger than that of the device we're on, and it's not even available at less than 782px. So we can't use it at all on mobile, and on tablet it can only give us a preview of what the screen looks like on tablet or mobile. The "Desktop" view on tablet doesn't reproduce the width of an actual desktop view:
When we choose to show/hide content based on breakpoint, we do so because a layout that works on a big screen doesn't necessarily work on a small one. We can't accurately preview a layout optimised for a big screen on a small one (some mobile browsers have the option to show the "desktop version" but the resulting view is rarely accurate) What I'm getting at is we should ignore the settings of the "view" dropdown altogether, because it's not a reliable indicator of the user's actual screen width. If we simply rely on media queries to show/hide blocks, we'll always get an accurate view, whether we're using the view dropdown or an actual mobile device. If we over-optimise for the unlikely event of someone wanting to edit a desktop layout on a phone, we risk creating a bad mobile editing experience for everyone. Not to mention that some of us still prefer to resize their browser window instead of using the "view" dropdown settings 🙀 |
Thanks for going deeper here. I think our instincts are aligned - I started with viewport in the first place on my POC, eventually combining it with the dropdown values. When I was working on that POC, I realized there is, in fact, is almost zero relationship between WP's standard breakpoints and the width values of the device dropdown. 🙃 The catch is, if a user hides a paragraph in mobile viewport while editing, and the switches to the emulated device width and it doesn't hide (which is exactly what will happen if we just use viewport widths), then that's inconsistent. For that reason, I'm not convinced we should ignore the device dropdown altogether, but you're right that it's not a reliable indicator. You mentioned "editing experience" - it's so true, and I couldn't agree more. I worry that we try to be too clever sometimes or mash new features into existing UI patterns. Thinking about this iteratively though, and guided by the notion that our device previews should accurately reflect their respective breakpoints, then I think @mtias's comment here indicates that, yeah, the viewport should trigger breakpoints, but let's start with device previews and iterate. It's behind an experiment and the viewport connection I've already half-done. Long term, I'm leaning towards better discoverability in relation to which blocks are hidden and which are not. If the sidebars are closed there is simply no way to know where hidden blocks are on the canvas, especially for those hidden in "Desktop" since "Desktop" device is the default setting. Might be just me, but I find that to be an undesirable experience. I don't want to have to look around for or guess where all the hidden blocks are! 😆 Wondering if there other ways to balance this? The most promising ideas so far in my opinion are:
Discussions on this feature are getting pretty fragmented over a few open PRs and issues, sorry for banging on. @jasmussen also has done a bunch of cogitating on this topic too. |
This is a bug! They should be the same. |
💯 I'm only guessing that the device values are different to make the canvas preview behave in unknown editor environments (1 sidebar, 2 sidebars, distraction-free). I couldn't find much context on the original PR, it was a while back, but maybe @tellthemachines remembers No harm in trying.
Agree, let's start there, even if only to keep the scope manageable. |
|
Just dumping this here for now, will come back to it. Breakpoint comparison
To centralize, at least for common values that relate to devices/viewports, the first thing that comes to mind is a JSON source with a build step to generate a const/scss import. Maybe. |
ramonjd
force-pushed
the
add/extend-block-visibility-backend-with-breakpoint-awareness
branch
from
e431b1a to
43da388
Compare
ramonjd
changed the base branch from
add/extend-block-visibility-backend-with-breakpoint-awareness
to
trunk
ramonjd
force-pushed
the
add/extend-block-visibility-clientside-state-with-breakpoint-awareness
branch
from
2dc9f66 to
d269794
Compare
github-actions
bot
added
[Package] Editor
ramonjd
force-pushed
the
add/extend-block-visibility-clientside-state-with-breakpoint-awareness
branch
from
6f0a95b to
669ed4d
Compare
|
Ack, thanks for making that table. Those are very clearly block editor UI breakpoints for handling the responsiveness of the block editor. However to my knowledge, the only two breakpoints that exist for the frontend, and the ones that the dropdown is attached to, are:
I vaguely recall those being hard-coded somewhere, perhaps in the individual blocks that leverage breakpoints. Notably it might be worth looking at the responsiveness built into the Columns block, for the stack on mobile feature: 
That one actually stacks on tablet 🙈 Since those values are out there and shipping, I think of them as the only two breakpoints that the editor currently supports, and before we add features to expand that range, I'd love to embrace them as the first step. Eventually I could imagine a Not sure if this is helpful or not, but my motivation for sharing is to reduce the variables for the first iteration, if at all possible. Ignore all the breakpoints created for the UI, and focus only on those 2 hardcoded breakpoints that the preview dropdown and shipping blocks use. Even with being able to responsively design for that, it will be a huge value. Building upon that: customizing those hardcoded values in clean way, then expanding them. One step, then the next. |
|
As I remember it, it might also be important to optimize this feature only for when the canvas is inside an iframe, and can actually show a correct preview. I don't recall where, but I think a version of the editor that is not iframed is still something that can be fallen back to in odd cases. In that case, we could show a notice or something. |
Makes sense to me. Good call! Dropping a link to this, which one day, might rein in the breakpoint wild west: |
|
ramonjd
force-pushed
the
add/extend-block-visibility-clientside-state-with-breakpoint-awareness
branch
from
669ed4d to
ff86397
Compare
| * | ||
| * @return {boolean} Whether the block has visibility restrictions. | ||
| */ | ||
| export const isHiddenInAnyDevice = ( state, clientId ) => { |
There was a problem hiding this comment.
Just double-checking if I'm missing anything, but it looks like this function isn't being used? What's the intended use for isHiddenInAnyDevice? (Seems like a useful function, but just wondered if it's a leftover from a previous iteration, or if it's being added for future PRs)
There was a problem hiding this comment.
Thanks for spotting that!! 👍🏻 You're right: it was a leftover from testing.
I've moved that kind of stuff to:
I'll remove 🙇🏻
- private selectors to support visibility checks for specific devices. - refactor related components to ensure consistent handling of block visibility attributes. Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> - introduce `deviceTypeKey` to manage device-specific visibility settings.
ramonjd
force-pushed
the
add/extend-block-visibility-clientside-state-with-breakpoint-awareness
branch
from
ff86397 to
46e1d25
Compare
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
Interesting discussion here. I can very much see the merits of using media queries in the editor CSS to handle the hiding behaviour as well (and it'd better match the site frontend / server-side behaviour). It could also naturally work with the device preview dropdowns as they wind up resizing the iframe.
That said, I think there's a compelling argument for having the hiding behaviour be tied to the device preview dropdown so that you're kind of online explicitly hiding on mobile / tablet if you use that device preview, rather than simply resizing the editor.
I think there's lots of good nuanced things to try here, and given that this PR is hidden (pun not intended) behind an experiment, my vote would be to land this PR as it introduces the basic behaviour in order to continue testing and iterating on the UI controls.
I suspect we'll want to tweak and revisit all this (and possibly wind up adding in media queries to editor CSS in a follow-up), but for now I reckon this LGTM.
|
Thanks @andrewserong! 🍺
💯 For reference @jasmussen posted an idea to tighten up the device preview dropdown: 
Even going off that there could be scope to rely on media queries by default (desktop). The POC demonstrates we can do this and accommodate both the dropdown and viewport width. |
ramonjd
deleted the
add/extend-block-visibility-clientside-state-with-breakpoint-awareness
branch
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org>
What?
Related to:
This PR makes blocks "aware" of their visibility settings and renders/hides them on the canvas according to their attributes.
Blocks are hidden in the editor when they have visibility restrictions for the active device preview via the existing
is-block-hiddenclassname.To test the backend:
Note
This PR does not add any UI changes or provision to update block attributes with visibility settings; it only allows "telling the block how to render itself on the canvas. The basic UI interface is in #74249.
How?
isBlockHiddento be viewport-awaredeviceTypefrom editor store to block editor settings using private keyTesting Instructions
For starters, the JS unit tests should pass 🍏
To test manually, enable the experiment:
Then copy and paste this into your post editor, then toggle the device menu.
Kapture.2025-12-16.at.17.10.57.mp4
Make sure to test with the experiment off as well. The last item should never show with the experiment on and off.