Gutenberg: Navigation Menu: handle overflowing Nav Items

[talldan]

Currently when lots of items are added to the navigation menu, the block forces the editor container to widen, which adds a horizontal scrollbar to the entire editor:

It looks kinda terrible!

Instead, we might consider adding a horizontal scroll container within the block itself.

See the table block for prior art on this.

[getdave]

cc @mtias because you've mentioned this as an Issue. It's already on the board and we will address it.

[getdave]

Needs decision

There are now ~two~ three distinct approaches

• Overflow with scroll - has several UI hacks to make toolbars work.
• Overflow with wrap on select - solves a number of issues but can feel a little jarring.
• _Always_ wrap - might cause a disconnect between editor and frontend.

@shaunandrews has also suggested having a "more" mechanic, but there we a number of edge cases / concerns raised by others around this.

I've also worked on a mechanic for allowing the parent Block to consume the child Block's toolbar which could help. But I believe @mtias doesn't see this as something the Nav Block will make use of.

I think we're at a point where we need to make a decision on the way forward.

[jasmussen]

We have another approach as well: Wrap. https://github.com/WordPress/gutenberg/pull/18431

It wraps it in the editor, and the frontend, keeping the two consistent. It's very little code, and it solves the overflow issue.

[folletto]

I think to answer this we need to go back to the principles the Editor is going for. While we aren't aiming for perfect accuracy, we want for the Editor to match as possible the frontend experience. That should be the driving principle for this decision. As such:

• I don't expect any navigation scrolling
• I don't expect any navigation to change layout when clicked

Which means that the only two viable solutions are only:

• Always wrap — most themes do this
• 'More' mechanic — nice, but I consider this for a v2 of this feature

tl;dr: Always wrap

—

I want to add a note here: long menus are bad. A design that "suggests" what happens for too long menus is actually beneficial in creating also better designed websites, because it nudges the user behaviour in the right direction. For this reason, it's not a problem if a long menu triggers a solution that might not _look_ clean. Because ultimately it won't on the front-end, and it would create a worse experience for _their_ users.

[mtias]

Just catching up with this conversation. A scrolling container doesn't make a lot of sense because it only "fixes" an editor issue; it doesn't communicate to the user what they are actually creating. In general, wrapping is what I would expect, as it shows the user that their navigation might need some tweaking. In the future, allowing users to opt-in to having all overflowing items grouped within a "more" dropdown could be nice.

The only issue with wrapping is the conflicts it might have with dropdowns, but that is also the case with the front-end. If you have a navigation menu that goes into multiple lines and also items with dropdown in the first line, it's going to be a rough experience for visitors.

tl;dr: I agree with @folletto

[getdave]

Thanks @folletto @mtias and @jasmussen. I think that's a definite 👍to moving forward with @jasmussen's wrap approach and get this Issue resolved.

@shaunandrews would you be ok to open another Issue to discuss the "More " option as a longer-term solution?

[karmatosed]

I also would 👍wrap and the more can come later. For what it's worth unless we have more on front then the idea of 'more' isn't really aligning.

[shaunandrews]

would you be ok to open another Issue to discuss the "More " option as a longer-term solution?

Sure, makes sense to move it to a future iteration.