Tabs: add option to wrap tabs instead of scroll

[david-vanderson]

@phatchman needed this for the grid demo.

I think TabWidget needs an options to use a flexbox internally instead of a scrollarea.

[phatchman]

Changing tabs so they are laid out in a flexbox, works for the horizontal direction, but not vertical. Maybe we need to add a layout preferred direction to the flex box to make it work for vertical?

However, I don;t think it looks that nice though. Maybe the tabs need to be consistent sizes or we need to hide all but the top of the tab when it wraps.

Something like this instead? With the top-line offset and covered by the bottom tabs, leaving a small amount of tab to click on.

Harder to implement, but I think that is more consistent with how tab sets usually work?

[phatchman]

Maybe a better solution is to follow the react material UI example.

They add chevrons to the tab widget for scrolling. It solves my issues that:

1. It is sometimes difficult to know there are more tabs and
2. It is hard to get to the extra tabs if you're not using a scroll wheel. (you can use keyboard nav, but I mean just by using the mouse)

Other options I've found in the wild:

1. Auto switch from horizontal to vertical if out of space.

   • This was not implemented well as it went vertical above the content. Even if it went to the left of the content, it could push the content far to the right if there are long tab labels. Don't think this is viable.

2. Wrapping as per my flexbox example above. (My example above looks worse because there are only a few tabs per line, exaggerating the space at the end of each row. So maybe it's not as bad as I think)

3. Scrolling with the chevrons as per material ui example.

4. I didn't see any examples where extra tabs are obscured. But I do remember it working that way, once upon a time.

So maybe we implement both? Chevrons for the scrolling option and flexbox for the wrapping option.

Not sure how well wrapping would work for vertical layout and whether this needs to be supported?

Adding for horizontal layout is trivial. Just needs the box created in the scroll area turned into a flexbox and either scrolling disabled on the scroll area, or scroll area not created. Plus adding required init options etc.

[david-vanderson]

So maybe we implement both? Chevrons for the scrolling option and flexbox for the wrapping option.

This sounds totally reasonable. I don't think we need to worry about vertical flex for now, unless you really want it.

The chevrons for scrolling is something that will need some thought.

Does clicking one scroll a set amount in an animation (closest to the material UI)?

Or does a mouse down scroll a small amount, but then we continue to scroll a small amount while held down?

• If this, ButtonWidget should grow an option for this, but we'll have to take care to make it framerate independent.

[phatchman]

Does clicking one scroll a set amount in an animation (closest to the material UI)?

It scrolls "one page" of tabs. So, if clicking on > and 3 tabs will fit in the scroll area, it will scroll all of the current tabs off and scroll in the 3 new ones. But some of the other just scroll one tab in at a time when you hit >. I guess this might actually result in one or more tabs being scrolled out. It can also result in more than 1 being scrolled in if a large tab is being scrolled out.

[david-vanderson]

Does clicking one scroll a set amount in an animation (closest to the material UI)?

It scrolls "one page" of tabs. So, if clicking on > and 3 tabs will fit in the scroll area, it will scroll all of the current tabs off and scroll in the 3 new ones. But some of the other just scroll one tab in at a time when you hit >. I guess this might actually result in one or more tabs being scrolled out. It can also result in more than 1 being scrolled in if a large tab is being scrolled out.

Scrolling "one page" is okay if there is an animation, but if we scroll instantly we'll have to scroll by less.

Do you have an opinion on which we should try between:

• single click scrolls some amount (with animation maybe)
• holding down the chevron scrolls a small amount each frame (maybe every fixed timestep)

[phatchman]

Do you have an opinion on which we should try between:

• single click scrolls some amount (with animation maybe)
• holding down the chevron scrolls a small amount each frame (maybe every fixed timestep)

I prefer the first, with animation.

I liken this to a normal scroll bar. In the pre-mouse wheel era, almost no one held down the little arrows at the end of the scroll bar to scroll it a little at a time. They clicked in the blank part of the scroll bar to scroll a chunk at time.

I think it is similar with tabs. If the tab I want isn't on the screen, then I want to see the next set of tabs "immediately", rather than waiting for them to scroll one by one, especially if the tab I'm looking for is at the end of the set.

It is probably a better touch experience as well? Touching once vs touch and holding?

[david-vanderson]

I agree with this. The only thing I worry about is if everything changes too fast, then it can be confusing as to what happened - not obvious it scrolled. So the animation fixes that. We might also want to scroll not the entirety of the "page", so you can see a little bit of the same.

But that is all guessing, and we can tweak it once it's working.