[Bug]: opt-out for TabList overflow behaviour

[davesteinberg]

Summary

Please provide an opt-out for TabList overflow behaviour. The behaviour is generally very useful, but there are circumstances where it isn't necessary and doesn't work correctly.

This is purely a development request.

Justification

My situation: I’m using tabs inside a HeaderPanel, which initially renders with width 0, then expands when it is activated. The effect seems to be that the TabList decides the tabs don’t fit (when the width is 0), so it shows the overflow buttons, but it doesn’t notice that the width increases when the panel is opened, so they remain there even though the tabs now fit. It’s only when you click the overflow button that it disappears.

But in this case, I know the tabs will fit because I’ve set a fixed width on the container and sized the tabs accordingly. So, it would be very helpful to be able just to disable the overflow behaviour entirely.

I discussed this with @dakahn on Slack, and he agreed that an opt-out could be generally useful.

Desired UX and success metrics

No unnecessary overflow buttons that disappear on click.

Required functionality

At its simplest, I'd imagine a new prop on TabList to indicate that overflow buttons aren't needed.

Specific timeline issues / requests

No, I was able to work around this with some CSS, but it might be helpful for others in the future.

Available extra resources

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[sstrubberg]

Hey @davesteinberg, thanks for feature request. We can do this from a dev perspective, but we aren't sure about it from a UX perspective. Any chance you or a designer on your team could post us some screen caps to better understand the intended outcome? It's hard for us to move forward on something like this without understanding some of the intended (or unintended) side-effects from a change like this. Thanks!

[davesteinberg]

@sstrubberg Thanks for the response. Here's a screen capture that illustrates what I'm describing:

Take a look at the right side of the screen. I'm using HeaderPanel here, which slides out from the side, animating from 0 to its final width. I'm splitting that final width evenly for the tabs, so I know there's not going to be any overflow. What I get by default is unnecessary overflow buttons (I believe the TabList is calculating that it needs them when the width is still 0) that disappear when I click one. What I want instead is what is shown here -- no overflow. I achieved this by styling the overflow buttons with display: none, but my thought is that it would be nice to provide a cleaner opt-out mechanism.

[sstrubberg]

Hey @davesteinberg, thanks for the screen cap and the additional context. Based on how you're describing the issue and the intended outcome, this feels like a bug. If we can address the overflow issue that you're experiencing out of the box as a bug fix, does that fix your problem?

[davesteinberg]

@sstrubberg For me, that would fix my problem. I'm not sure if there might be any other case where it might be helpful to disable overflow.

[neo]

I'm coming from a semi-related issue, that on the contrary, I was trying to add more tabs after it's initialized, but it wouldn't be considered as overflow because isScrollable in TabList only checks once at the beginning and on resize.

And I'm thinking, if we update isScrollable more frequently on tab changes, would it solve both problems?

[wood-doug]

I have the same issue, but my expanded tab list is not large enough to show all the tabs so opting out wont work. The tablist needs to hook resize and recalculate scrolling

In my case, I have a slide out side panel with tabs. the panel can be configure to start open or closed. If it starts open, tab scrolling works correctly. If it starts closed, it does not