jattasNI
commented
3 weeks ago Notes from team review:
- there shouldn't be a visible scrollbar on any OS
- when a tab has keyboard focus, left/right arrow keys should continue to move to the next tab as they do today. That tab should scroll into view if it was off screen.
- don't need to worry about keeping the current tab within view
- TBD whether the scroll buttons are tab-focusable
- start by matching shoelace's behavior when an arrow button is clicked: scrolling one "page width" (i.e. all the currently visible tabs scroll out of view). We can start there, play with it and see how it feels.
- we should have usage guidance that tabs shouldn't be given very long names. In case that's out of an app's control (e.g. user-specified names) we could consider following our established pattern of having a reasonable default max-width on each tab but allowing apps to override it. This will probably require other styling changes to behave well.
🎨 Visual Design Request
📌 Request Background
We've received multiple requests to handle tabs that end up being wider than the parent container. I.e. Long titles on the tabs or many tabs, or both.
I'm proposing that we use a common pattern, and allow the tabs to scroll on overflow.
🧑🔬 Research
The following design systems scroll the tabs controls on overflow. To pick one, Shoelace does a nice job of showing that the view is scrollable with clickable arrows.
🎯 Core Requirements
If we were to implement the Shoelace pattern, I assume it would look something like the following:
We wouldn't reserve space for the arrows, but if they're required they would appear.
Any concerns with this approach?
🥅 Acceptance Criteria