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.