wip: Hide overflowing navigation menu items #28646
Conversation
Co-authored-by: Jon Surrell <jon.surrell@automattic.com>
|
Size Change: +1.05 kB (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
|
This is cool, I can't wait to test it! I'm getting this error when running:
This is despite a few npm install's, so I suspect you forgot to include a module that's needed. |
Sorry about that, it's fixed now. |
|
This is what I see, editor:
This is what I see on the frontend:
Quick notes:
I'm missing the overflow button. I'm guessing that's also my theme? But overall, the popping off of menu items seems to work really well, so high level this seems promising. It opens a few questions around editing, specifically around how you edit the menu when some items are in the popover. I think the approach we should try and find here is: only pop off items when the navigation block is not selected. As soon as you select the navigation block, you see every menu item and can edit. This embraces the "unselected is a preview, selected has additional controls" principle. Another thought, and perhaps you're already pondering this, instead of building this into the navigation block, could this be a separate "Responsive Menu" block? Anything you put inside it is a hamburger on mobile, and shown on desktop. And this "gradual reveal" is then an option of that block — showing the sequence of content base on available space. I could see it being useful for other blocks, such as social links. Finally, I wanted you to be aware of #28265. That PR creates a single "Page List" block which outputs all pages, as a single block. Ideally the frontend should be unchanged, so I suspect the primary challenge will be the editor preview, and I think we can probably just fake that with overflow: hidden;. |
vcanales
force-pushed
the
hide-overflowing--navigation-menu-items
branch
from
bca3789
to
70951cd
Compare
That is correct :)
Actually, I imagine this as the Dropdown showing up when the Navigation is selected. Perhaps this allow the user to, for instance, use a different style for a Block when it is displayed within the dropdown menu—this is future talk though.
I had not though of that. I'm not sure if I'm understanding this correctly— do you mean having a normal Navigation block, and then a responsive block within it, or both blocks living side by side, with only one showing up depending on the resolution?
Thanks for bringing up. Indeed it could pose some challenges, both in code and UI. The latter because we'd have Dropdowns within Dropdowns if the pages element is made invisible. I'll play around with the work on that PR later to check out how it behaves at the moment.—it looks like it's quite close to getting merged. |
I mean basically this hierarchy of blocks, forgive the crude ascii mockup: In the above, the Responsive Menu block would ensure that the Navigation and Paragraph block collapsed into a hamburger menu on mobile, and showed up on desktop. This Responsive Menu block would also have the option to "pop off" these items into the overflow menu, as this effort explores.
Potentially we could show menu items just as indented submenu items when in the overflow menu, rather than fold-out sub sub menus. |
|
Ah yes, that makes a lot of sense. The current method assumes some things from its children, such as their height and that they are |
Attempting to fix e2e failures on a "Front Page" template selector. It looks like tt1-blocks no longer supplies a front-page template, and using Index should work as the tests were not reliant on the specific template.
* Reproduce bug * Fix for all blocks selector There may be blocks that don't support any style but still have the presets declared as settings. In these cases, we still need to process the settings.
vcanales
force-pushed
the
hide-overflowing--navigation-menu-items
branch
2 times, most recently
from
13814e7
to
73925b6
Compare
* Try: useMergeRefs * update lock file * Rebase fixes * Add docs * Clearer documentation * wip * wip * Add docs for unit tests * Convert new additions
vcanales
force-pushed
the
hide-overflowing--navigation-menu-items
branch
from
73925b6
to
7716cb9
Compare
vcanales
force-pushed
the
hide-overflowing--navigation-menu-items
branch
from
7716cb9
to
310156f
Compare
vcanales
force-pushed
the
hide-overflowing--navigation-menu-items
branch
from
befeafa
to
98c55db
Compare
|
Closed in favor of #30047 |
Description
This PR tries to implement automatically hiding items that do not fit on the horizontal navigation block, and showing them within a dropdown instead, following the approach discussed in #27131 (comment) (codepen). The approach uses CSS and JavaScript to detect when an item is being 'wrapped' (moved to a new line).
The current challenge is applying this detection to the Navigation block's InnerBlocks, which requires identifying the underlying DOM element to add CSS classes to it and to move it to a different container.
In progress
How has this been tested?
Screenshots
Types of changes
Checklist: