-
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
Try: Flip orientation of submenus that are towards the right of the viewport #30342
Conversation
Size Change: +575 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
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.
Tested this and it works as described!
Thinking out loud here — do you think it would be necessary to flip the arrow that indicates the presence of a submenu when elements are flowing left instead of right? This might not be possible without JavaScript, but in testing it felt slightly "surprising" to see the submenu pop up on the opposite side of where the arrow indicates.
Test navigation menus justified right or space between, with a bunch of submenus.
In testing, I found an issue that is tangentially related to the limitation where deeper submenus add width to the site indefinitely in order to flow; is it possible to take the changes here further in order to get rid of this issue for all alignments?
Editor
Frontend
The thought occurred to me, so I looked to see what the Mac does, and it doesn't change the setup: Probably they evaluated the systematization of label / icon in menus, and found that it was more important to have the icon show up in a consistent place, than to swap place based on direction:
So far we have two ingredients in play to mitigate it. This PR, which flips the direction on items we know are on the right, and a separate PR to limit the depth to 5. The 3rd obvious ingredient would be to detect using JavaScript when a submenu bumps against the edge, and then flips direction. While that's something we can do, I think we should put it at the back of the queue, as it's very probably going to be quite complicated. The JS would have to be output in editor and frontend, be resilient in both cases (editor isn't yet iframed), and be aware of arbitrary width dropdown menus. In the mean time, two other aspects could likely mitigate this further. Basically, when you have enough submenu nesting that switching direction becomes necessary, you might want to toggle "Unfold nested submenus" as suggested in #30370. Or you might want to combine that with a mega menu instead, for which I had an idea this morning, how to address in a simple-ish way: #23745 (comment) |
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 answer — I had not realized that this how macOS handles that situation.
And unfolding sounds like the perfect solution for the concern that my testing generated.
LGTM!
Description
Navigation block menus open down and to the right. Cool.
But this is not so cool, when you're reached the right screen edge:
This PR fixes that by flipping the direction a menu opens, when the menu is justified right, or for the last item when the menu is justified space-between:
This PR pairs well with #30199.
But even with both this and 30199 in place, it will be possible for a theme to make a menu that gets viewport cropped. However we shoul allow this, because:
How has this been tested?
Test navigation menus justified right or space between, with a bunch of submenus.
Bonus points if you test the Page List block.
Checklist:
*.native.js
files for terms that need renaming or removal).