Updates the behavior of the top toolbar fixed setting #47277
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +1.39 kB (0%) Total Size: 1.35 MB
ℹ️ View Unchanged
|
draganescu
added
[Type] Enhancement
Contributor
|
I think my biggest concern about this change is that you lose access to a bunch of tools if a block is selected. As a workflow, a common pattern for me on long documents is "Edit Block > Document Overview > Select Block > Edit Block"; and that workflow isn't available to me with this model without first removing focus from a block. That's easy to do with a mouse, but less trivial or discoverable from the keyboard. One thing that might help with this would be if there is a way to deselect the block while in the top toolbar edit tools, so that if you've navigated all the way back to the editing tools, you can get back to the top toolbar immediately. Alternately, the edit post header controls could be placed in a popover at the beginning of the toolbar edit tools, so that those controls are collapsed rather than removed. |
Contributor
Author
|
@joedolson in the final shape of this there is a button next to the block tools on the left (an up arrow) than can be used to go back to document tools, and there is a button on the right (a button with the block icon, a paragraph in the design) to go back to block tools, all while having a block selected. This PR is just not there yet. Do you think the toggle solution proposed by the design is good enough? |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
d658902 to
78aebb6
Compare
Contributor
|
I feel like the toggle to switch between menus should stay in the same position. Effectively, the arrow control to switch to the document tools and the paragraph tool to switch to the block tools are just a single switch that changes between toolbars, and having one of those tools at the start of the toolset and the other at the end feels strange to me. I think it would be more predictable if the switch control was always in the same position. But yes, that would help a lot! |
This comment was marked as outdated.
This comment was marked as outdated.
14 tasks
Contributor
|
I am not in favor of this change because of context issues. Let me take a moment and paint some thoughts.
Just my thoughts without testing. Right, wrong, not even close? Thanks. |
Contributor
I think you're right on the money that it's going to be difficult to get this feature right. It isn't the default option though, so one good thing is you shouldn't ever need to enable it. (though I realise it should also work in a good way anyway even when enabled.) One of the main thing that stands out to me is that the tab order is going to be hard to get right. Currently users expect to be able to shift tab from the block to the block toolbar directly without passing through Options, Settings, Publish and Preview buttons. But this change will put those buttons in the way, and that won't be very convenient. It's worth noting that plugins can also add buttons to this area, which means there could be quite a lot of tab stops. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
64099ef to
6c7c8e8
Compare
Contributor
|
Here is an idea. How about you visually hide the document tools toolbar and then add events to show it when focus passes through it? That way the experience does not change for keyboard users but you still get the appear/disappear functionality. I simply cannot support adding another tab stop to this area. I was also unaware that there was a slot fill in that area. That really could turn messy one day. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
6c7c8e8 to
861590b
Compare
Contributor
Author
@alexstine I don't grasp how that would work? Does it mean for keyboard navigation both toolbars will be available at the same time? |
Contributor
|
@draganescu Correct. Then when the toolbar receives focus, it will be shown visually. Completely removing or hiding the first toolbar from the DOM I do not think is a good idea. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
861590b to
06e9f82
Compare
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
06e9f82 to
4d42882
Compare
This comment was marked as outdated.
This comment was marked as outdated.
draganescu
changed the title
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
35cd696 to
5cb233f
Compare
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
4050a07 to
3421026
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Contributor
|
Yeah, I am not a fan of the appearing/disappearing DOM elements either but it seems to be the way of the future with React/Vue/other frameworks. Not the largest issue in the world but things would be less complicated if things did not disappear from the DOM. Something a lot of times sighted people and designers take for granted how hard these interactions can be for people without visual indicators. I totally support conditional rendering for dialogs but it is way over used in Gutenberg even outside of this PR. |
Contributor
Author
|
I have tried but not succeeded in a different approach, yet I still tink it's possible:
Everything else stays the same for mouse users with buttons that can show and hide document and block tools. My challenge was where to place the block toolbar in fixed mode to respect the bullet requirements above. |
- wraps the edit post header in a slot fill provider - implements a temporary behavior that shows document tools when no block is selected - updates the block tools and parent selector to appear properly in the new place
…slot fill provider
- restores fixed toolbar on mobile viewports - adds hover states to toolbar toggles - adds the correct level up icon - moves CSS to the right files Co-authored-by: Joen A. <[email protected]> Co-authored-by: James Koster <[email protected]>
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
b85ff40 to
0988ac3
Compare
Contributor
Author
|
Ok, here is the current state: playing around with the DOM position and some heavy focus management, I can achieve the state in the video. toolbar-focus-aria.mp4There still is work to do:
|
Contributor
|
@draganescu It is working much better. Keep going, you are close. Thanks. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
15a38d0 to
161eb93
Compare
Contributor
Author
|
TL;DR; there appears to be a way to not break the keyboard interaction at all but it has sent me basically to square one. With the help of @MaggieCabrera and @jeryj I have found a way to reuse the fixed block toolbar and not have to change where it is rendered. Instead, I can simply reposition it on top of the document tools and style it to fit visually there. This has the great advantage that all the keyboard interaction remains the same! No more tricks. However it has some challenges which I am looking into:
As far as the approach in this PR, Alt+F10 is handled by a hook that manages focus when this keyboard shortcut is used. This hook is not specific to block toolbar but to all navigable toolbars. Because this PR puts two navigable toolbars in the same container Alt+F10 always selects the 1st which is document tools. The other thing I still have to see if I can change this in a reasonable way (unlikely). |
Contributor
Author
|
Closing in favor of #49634 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Closes #40450
Updates the behavior of the top toolbar fixed setting.
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
N/A
Screenshots or screencast
top-toolbar-parent-selector-focus-show.mp4