-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block toolbar: split switcher from mover and simplify styles. #23971
Conversation
Size Change: -361 B (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
1d8e1c1
to
5cead2b
Compare
There's still a lot of discussions about that and different opinions. I removed the backport label but if it an agreement is reached and it makes it before 5.5, we'll add it back. |
36dd4f1
to
b57c1e7
Compare
Rebased since #23980 got merged. |
This comment has been minimized.
This comment has been minimized.
b57c1e7
to
682d66c
Compare
This comment has been minimized.
This comment has been minimized.
682d66c
to
2b14435
Compare
This comment has been minimized.
This comment has been minimized.
df0847c
to
e7a9dcb
Compare
Rebased again. |
The accessibility team would definitely like to see this happen in WP 5.5; it would help a lot in mitigating some of the challenges with this part of the control. |
Only show parent block selector button and block outline when hovering the block icon.
e7a9dcb
to
9672373
Compare
This makes the movers a little less visually obvious; With the added divider between the block icon and the movers, the context feels different. My instinct tells me that the movers should be somewhat special in comparison to the rest of the buttons in the block toolbar. Looking back at @diegohaz's suggestion, I like the extra spacing instead of a more explicit divider; The space helps connect the movers to the block in question, and feels overall visually simpler. I wonder if this PR could accomplish this by hiding the divider between the block icon and the movers. |
I am pinging a few folks who added a comment to the issue, so they have a chance to take a look at this PR. |
Semantically, though, the controls should be divided by a line because they're in separate This also ties in another issue (that hopefully someone else can solve): the movers use the same icons as the accordion panels, Another issue is that the mover buttons being stacked in the first place makes it a lot more difficult to where one starts and ends. The icons are so close together they appear like a single button. There's yet another issue tying into all this: we need to have a visible drag handle. Showing a drag-hand cursor when hovering the mover buttons was deemed bad for a11y (all buttons should use the standard button cursor), so it was reverted. But now there's no indicator of any way to drag blocks. There ought to be a clearly defined drag handle somewhere. And to pull that off, the movers will ultimately have to be split apart into 2 full-size buttons... probably with a drag handle in-between. These all have to be addressed in order to undo a11y regressions that WP 5.5 is introducing. I realize that fitting 3 full-size buttons into the block toolbar is asking a lot. But I think that speaks to a larger issue: we need a way to show controls more contextually. We can't always show the block movement controls, because there simply isn't enough space to do that. In general, there's simply too many toolbar controls to show all at once. I've been thinking about recent explorations like #24021. Assuming it can be done accessibly, I think we should apply this concept to the movement controls: by default, a movement controls button would appear in the toolbar. Clicking it would swap the currently visible controls with all the movement-related ones. This would allow us to not only show up, down, and a drag handle, but also additional controls like "move to top" or "move to bottom". Anyway, this PR was intended to be a compromise to improve the situation for now by removing some of the weird special-casing that makes the current situation bad for a11y. Trying to step back a bit closer to the current design in If this PR isn't a good enough compromise for everyone, I suggest we look into the full-toolbar-replacement idea and try to get it done in an accessible way in time for WP 5.6. |
In my opinion, we can move affirmatively with this. And I think we’ll need to revise soon how the dividers and grouping work in the anatomy of the block toolbar and its different cases. Because this change introduces complexity in the hierarchy of the controls, their taxonomy, and also establishes a busier toolbar. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! This is what I see:
High level, this seems like a good enough compromise that keeps intact the benefits of having the mover control in the toolbar (no lateral overlap in nested contexts, consistency across mobile and desktop, works identically for vertical and lateral movement). Closes #23760.
Keeping Pablo's comments in mind, let's try it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Thanks!
Thanks, everyone! 🎉 |
It's great to see this happened! 🎉 Thanks @ZebulanStanphill |
* Block toolbar: simplify switcher/mover styles. * Move mover out of block-switcher-container Only show parent block selector button and block outline when hovering the block icon. * Reduce style specificity and add missing comment.
Description
Following the discussion starting here, this PR simplifies the block toolbar styles so that the switcher and movers are shown in separate toolbar groups, with the standard spacing between the two. They were already technically in separate toolbar groups, but the styles obscured this to try and show them closer together.
To ensure that the parent block selector button and block outline only show when the block icon is hovered, I had to move some elements around a bit. As it turns out, this allowed me to remove even more special-case CSS.
I initially tried to create a PR that simply increased the space between the switcher and mover, following this comment by @diegohaz. However, this proved to be really, really complicated to try and implement. As it turns out, going the next step and just using the standard styles was a drastically simpler solution.
As the accessibility report found the combined switcher/mover area to be a regression, accessibility-wise, I'm tagging this with the "Backport to WP Core" label in the hope that it will be included in WP 5.5, as suggested by @afercia.
Screenshots
Checklist: