Tabs with longer strings may trigger horizontal scrolling of the panels they live in about gutenberg

[afercia]

This requires some design feedback first Cc @WordPress/gutenberg-design

I can think of two options:

• Either allow the tabs flex layout to wrap to a new line
• Or establish strict guidelines for 1) the amount of tabs in a narrow sidebar 2) the length of the tabs translatable strings

Three horizontal tabs in a narrow sidebar seem not ideal in the first place.

[jasmussen]

Would it make sense to have a new dedicated label for text-labels-only mode? There are quite a lot of issues related to the feature, perhaps enough that it deserves its own category. I'm not sure that allowing wrapping, or setting best-practice guidelines (since those can be broken by third party consumers) is necessarily the best way to do handle the overflow, and overflow is something you'll see in a slew of places across tabs, block toolbars, popovers, modals on mobile. Would transforming when text doesn't fit be a solution?

[afercia]

To me, the root issue for this case and for similar cases in the editor UI is the usage of fixed heights.

On the web, text is supposed to reflow and re-adapt when the container size changes. I would say it's the beauty of the web. Attempting to design a pixel-perfext design with fixed heights and sizes is often pointles and introduces problems. Any container should allow its content to reflow and adapt.

Instead, I see the trend in the editor is to try to adapt the content to the design. It should really work the opposite way. The design should be built around the content.

It is also worth mentioning that, from an accessibility perspective, any layout should support text-only zoom up to 200% without loss of content or functionality. Fixed heights typically break tet-only zoom.

That's the reason why in core all buttons and form controls have been changed to not use fixed heights and now they can scale with text. The saem principle should be used in core, also for the tabs and any other text container that uses fixed heights,

On the other hand, I'd be totally in favor of using shorter labels. Some labels are visually hidden by default and you realize that are too long only when made visible. However, I'm not in favor of providing pairs of labels with an additional bale for 'show button text labels' because:

• The editor should provide equivalent information for all users, regardless of the editor preferences users set, device and assistive technology in use.
• It would double translators work.
  See https://core.trac.wordpress.org/changeset/46243

[jameskoster]

I think this is an issue with the Tabs component, rather than the 'Show button text labels' feature. It should better handle long labels, and adapt more elegantly to narrow spaces.

This is bad, but can probably be improved significantly with one or two small tweaks:

tabs.mp4

Options to try:

• Horizontal scrolling (of only the tab row container)
• Truncate extremely long labels (with tooltip)

A hacky mockup:

tabs.mp4

[afercia]

Just noting that horizontal scrolling is never recommended because it isn't a great experience for keyboard users. Also, browsers handle scrollable elements in a different way, see explanation at #45809

Truncating content could be explored but I don't think it's the best option. Rather, the UI should be designed around content.
I'd think all this kind os content manipulation would treat the symptom rather than the actual disease. The root problem is is that a narrow container like a side panel has very limited horizontal space for horizontal tabs.

[jameskoster]

Another option would be to allow tabs to wrap. The current design doesn't particularly lend itself to this though:

A revised visual treatment which doesn't look so clunky when wrapping could be a solution:

But obviously this would have a widespread effect and require careful consideration.