Block API: Add block visibility control support and UI #71203
Conversation
t-hamano
added
[Feature] Block API
|
Size Change: +2 kB (+0.1%) Total Size: 1.92 MB
ℹ️ View Unchanged
|
t-hamano
force-pushed
the
block-visibility
branch
from
9715418 to
6436944
Compare
|
Flaky tests detected in 7849d2f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17030899114
|
t-hamano
requested review from
spacedmonkey,
ellatrix,
ajitbohra,
fabiankaegy,
juanmaguitar and
ndiego
as code owners
|
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 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. |
|
Nice work. I just shared some mockups in the main issue, which instead of dimming/overlaying the hidden block, actually hides it. In my comment I acknowledge the pros and cons to doing that, but since you already have a PR ready, I'm wondering if actually testing out the theory with something real isn't the best way to help decide. Beyond surfacing the potential need for focus handling, my hope is it'll make the behavior very obvious and intuitive in a way that opens up future opportunities. What do you think? |
|
Working well thus far :) Thanks for all your efforts here. It's interesting to try this with inner blocks/container blocks. I think we can learn a lot from block locking here in terms of UX: hiding.blocks.mov |
I'd suggest that both would actually be useful (also commented something to that effect in the issue):
Future compatibility with breakpoints or other variables can be left open if we keep the data structure flexible, though @t-hamano has already thought about this. Oh, I don't know, something like: |
|
I've been experimenting with visually hiding blocks in the editor. My first attempt was to simply not render the block when it's not selected. As expected, this caused some issues:
Videob20c717a1766a916e3ed3ce5f9ea12b2.mp4To solve this, I tried the following approach:
This should solve the two problems mentioned above. The technical details of the approach are as follows:
Let me know what you think! 4f5707495143576a960f84d060761c20.mp4 |
|
What does it look like, feel like, if you truly just hide it, exactly like in Figma, with no indication in the canvas, no block that appears when selected in the list view? You mention this:
1 doesn't seem a problem, you hid the block with an intent for it to not show up, so the lack of visual feedback here is just WYSIWYG. Can you expand on the second one? I'm a bit keen to make sure this is properly explored, because it seems like the simplest possible solution, the one that matches the user expectation the most, whereas all the alternatives have tradeoffs. If the main challenges around focus management are taken care of, it might be the smallest PR we can land, to get a feel for it, and options to revisit it could be to add a toggle in preferences to show a placeholder for hidden blocks. In doing so, we can explain the tradeoff in context of the toggle. |
This reverts commit c3f7135.
The cause of this was that the calculation of the insertion indicator placement failed because the block was visually hidden. Excluding visually hidden blocks seems to work fine. What's interesting is that indicators appear both above and below visually invisible blocks, even though I didn't add anything special process. This may be preferable, as it means the user can choose whether they can move or insert blocks above or below the hidden block. 4d7ccdf699c24afd0cb7696a3df7e822.mp4 |
|
Technical Note: Interestingly, I noticed that the |
That's a bit frustrating. I think the naming will be confusing for many. Maybe we should deprecate it for a private, renamed alternative ( |
This is interesting, and thanks so much for showing this video. This aspect also surfaces additional options for future exploration as far as where we can take this depending on feedback. That is, perhaps a hidden-block-placeholder could appear as soon as you drag blocks. The context here is a mental mode-shift: now you're rearranging blocks, it makes sense to surface hidden blocks in a way that makes less sense when you're not dragging blocks—that's the preview/editing mode. Similarly this way of thinking of contexts could surface hidden-block-placeholders in zoom out mode, or in template editing mode (i.e. isolated editing), or simply when you press and hold a modifier key (think holding ⌘ in VSCode to navigate to packages, or holding modifier keys to surface keyboard shortcuts). If need be, this could even be a differentiation between the in-progress Write/Design modes. To be clear I'm not proposing any one specific path forward with the above, this is mainly sharing some concepts in case they inspire ideas. I also still feel like it would be valuable to move forward with the simplest possible PR, exactly to help spark these ideas. Nice work! |
You can test it with the latest commit, but I've implemented the following behavior: bda6ba0fa3af135556f7c7d390667793.mp4 |
|
Thanks for the iteration. How does it feel to you? Although I can be tempted to start with less than this, the behavior here feels pretty reasonable. There are some visual details around the hidden placeholder that could be worth refining, e.g. perhaps [closed eye icon] Heading may be sufficient and scale to more contexts (such as very narrow containers) etc., which will be useful considering items you might want to hide in the header or footer, other horizontal contexts. But as is, I think it's probably time to get broader feedback, so another ping to @WordPress/gutenberg-design would be good. |
First implementation for #50756
What?
This PR adds a new block API and UI for toggling block visibility
in the frontendin both the frontend and the editor..Note: First of all, I would like to discuss why this feature is necessary and what kind of extensibility it can potentially offer in the future. Any feedback would be appreciated.
Why?
Sometimes users may want to edit blocks in the backend without affecting the frontend, for example, a section that is not yet ready to be published.
How?
Implementation details are as follows. Many of the specifications are similar to Block Lock.
blockVisibilityblock support except for some generic blocks, which defaults totrue. When a block is hidden, its state is saved inattributes.metadata.blockVisibility.isBlockHiddenprivate selector to the@wordpress/block-editorpackage.blockVisibilityattribute isfalse:Testing Instructions
Testing Instructions for Keyboard
In the List View, use the Tab key to focus on the hidden block. Your screen reader should announce something like this:
Screenshots or screencast
7e3b756925b3e09bc0c6050f75602f49.mp4
Tasks
Below is a list of things I can think of that need to be addressed and discussed.