Navigation block: Hide more than N items

[scruffian]

It would be useful to have an option for the navigation block to set a maximum number of items, and then hide the rest, like this:

[mkaz]

@scruffian I'm taking a look at this one and trying to figure out how to surface this so it is available to themes. Adding as an option to the block is straight-forward enough, but how would you use it within a theme?

Playing with a Codepen (https://codepen.io/mkaz/pen/zYKMyLw) and seeing if possible to use the nth-child selector to show the nav menu, and I'm not sure how you would group the hidden part without modifying the navigation markup.

[scruffian]

The way that themes would use it would be through theme.json.

I think you're right there would need to be some changes to the markup to make this work. Is that a problem?

[aristath]

Ideally, this shouldn't be a set number of items... Instead, it should just hide the items that don't fit. This way it will work for all viewports with minimal changes

[scruffian]

@aristath yes that would be much better!

[jasmussen]

Essentially what we need is in this codepen. I wish that were possible with no JS — I think we could actually come as far as menu items disappearing one by one and a menu appearing only when necessary. The tricky bit here is, I don't know how we'd keep track of which items to show in the overflow menu or not.

So I believe we do need some JS at least handle what shows up in the menu and what doesn't.

[aristath]

Hmmm thinking about this some more, perhaps we don't even need to collapse them vertically? This codepen uses a lot of JS and I'm just using it to show an alternative concept, but it is conceivable we can build something like that (but obviously better) using plain CSS :thinking:

[jasmussen]

Scrolling horizontally, perhaps with a button to indicate the overflow, we could probably do that as a baseline minimal responsiveness for menus.

But I think there's value in the proposal here, which pops off the items into a dropdown menu. That is, if it doesn't get onerously complex once we have submenus on end — those obviously have to be handled elegantly by the overflow menu also.

[jasmussen]

Another option is to take inspiration from @shaunandrews' "full screen menu" concept outlined in #24604. Basically, as soon as there isn't room for a menu item, a button shows up, which when clicked, opens the entire menu in a fullscreen modal.

[scruffian]

I think from a theme perspective we'd like both approaches...

[vcanales]

Scrolling horizontally, perhaps with a button to indicate the overflow, we could probably do that as a baseline minimal responsiveness for menus.

I have mixed feelings about horizontal scrolling, particularly because scrollbars show up differently between browsers—some of them being very ugly.

The tricky bit here is, I don't know how we'd keep track of which items to show in the overflow menu or not.

I tried an approach that uses overflow: hidden, a fixed container height, and some JS in order to detect which menu items are being wrapped, and therefore hidden from view. The same "wrap detection" can be used to figure out if it's time to show a different menu without knowing how many elements there are, or their widths, beforehand.

https://codepen.io/vcanales-the-styleful/pen/eYdXWgz

It has a few things going for it:

• Uses CSS to move elements out of view.
• Uses CSS to trigger the visibility of the dropdown.
• Uses just a little JS for class manipulation and element wrap detection.
• Debounced/throttled with requestAnimationFrame, which improves performance.

And a few drawbacks and things that I couldn't figure out in the time I gave myself to give it a try:

• Requires knowing the exact computed height of the nav items, needed to set a fixed nav container height.
• I couldn't figure out if it would be possible to style the elements that get wrapped in a way that would make them look grouped in a column instead of in line. With a bit more JS, we might be able to move wrapped elements into their own container.

I'd love to iterate on this if you think it's going somewhere :)

[jasmussen]

I have mixed feelings about horizontal scrolling, particularly because scrollbars show up differently between browsers—some of them being very ugly.

Yep, I would consider this the very last resort of responsiveness. On mobile, it can be a good experience to swipe horizontally, though, so I think it's a nice option to have.

https://codepen.io/vcanales-the-styleful/pen/eYdXWgz

I like this one a lot! It actually pretty directly solves the ticket as outlined. If Ben can take a look at the codepen to see how well it works, I would love to work with you on the next step of actually integrating it into the menu block. What do you think?

[scruffian]

This is the design I had in mind for this:

The codepen is almost there, but it would be great if the more menu could stack vertically...

[getdave]

Just a note to say we did tackle this in the past here

https://github.com/WordPress/gutenberg/pull/18336

Not sure if it will help but could be good context for what paths have already been explored.

[vcanales]

I would love to work with you on the next step of actually integrating it into the menu block. What do you think?

Absolutely!

The codepen is almost there, but it would be great if the more menu could stack vertically...

I think we can leverage the wrap detection to stack wrapped elements vertically by moving them to another container. I'll give it a shot when I have a moment.

[jasmussen]

There's some relevant discussion in #22824 also. Any PR that fixes this one, probably also fixes that older one.

[getdave]

@MaggieCabrera this feels very similar to what you have tried in other PRs. What are your thoughts on this? Is it achievable to make this automatic vs having a hard coded number of items?

@mikachan I'd also value your input from a Themes perspective on whether this feature is even desirable.

[MaggieCabrera]

My exploration was a little different but what I found is that we have two problems that we may or may not want to find a "smart" solution for:

• When the nav items are too many and they wrap into a second line
• When the combination of user inserted blocks PLUS a nav block results into wrapping elements because said combination doesn't fit in the viewport

The first one we could find a reasonable solution, potentially with just CSS and container queries. The second one not so much, since there is no way to know about how the user decided to build their header. Did they use grid? a row block? columns? It also happens that the second thing happens before the first, so it's the problem most use cases will want to fix.

After trying and failing to solve this myself and discussing this with design, I think trying for a smart solution will not land a good solution, so maybe we need to think about how we want to expose the option to users. I think this is one of the cases where we need to wait for a more holistic solution on responsive controls before we find a specific solution for the navigation block

[getdave]

Thank you for that helpful recap 🙇

wait for a more holistic solution on responsive controls before we find a specific solution for the navigation block

...or do we need some blocks to push the boundaries and start introducing these controls behind experiments so when it comes to a holistic solution we have something to build upon?

[MaggieCabrera]

Thank you for that helpful recap 🙇

wait for a more holistic solution on responsive controls before we find a specific solution for the navigation block

...or do we need some blocks to push the boundaries and start introducing these controls behind experiments so when it comes to a holistic solution we have something to build upon?

We've tried that with the nav block and it seemed like a very block specific solution

[mikachan]

I'd also value your input from a Themes perspective on whether this feature is even desirable.

From my experience, I don't believe this feature has been requested much by theme builders, although that's not to say it wouldn't be a helpful feature.

I think this is one of the cases where we need to wait for a more holistic solution on responsive controls before we find a specific solution for the navigation block

+1 for waiting for a more holistic solution to responsive controls before we address this on the Navigation block.