Adds the scroll prop to Tabs. If scroll={true} and there isn't enough room on the screen to show all the tabs, only that Tabs that fit will show and left are right arrows will be displayed on either side of the Tabs header and can be used to scroll left or right to see additional tabs. An interval can be passed to scroll like so: scroll={{ interval: 2 }} to define the number of tabs the left and right arrows will move by.

Some thoughts on the API surface ...

• From a language standpoint, I would expect scroll={true} to mean that we would show a scrollbar to allow scrolling through the tabs.
• If our current behavior is to wrap when we run out of room for the tabs, I'm wondering if we should consider this a bug and just have the new behavior be the default. I'm wondering if the current wrapping behavior would ever be desirable?
• From a language standpoint, I would expect interval to be related to "time". I wonder if "step" would be a better term.

This is coming together really nicely.

A couple of behavioral/stylistic comments.

1. The focus indicator is getting cut off:

2. When I tab to the "right" control and then it becomes disabled, the focus is lost. I might expect it gets placed onto the last tab potentially?

From a language standpoint, I would expect scroll={true} to mean that we would show a scrollbar to allow scrolling through the tabs.

Yeah, I can see how naming this scroll would cause confusion. Beza and I are trying to brainstorm a better name for this. Definitely open to suggestions if anyone has ideas.

If our current behavior is to wrap when we run out of room for the tabs, I'm wondering if we should consider this a bug and just have the new behavior be the default. I'm wondering if the current wrapping behavior would ever be desirable?

I can't think of a case where the wrapping would be desirable. My only hesitation with making this the default behavior is that we have a storybook story Tabs/Responsive that is advertising that this is how we have been handling responsive tabs. So it feels like something that we have been considering a feature up to this point.

From a language standpoint, I would expect interval to be related to "time". I wonder if "step" would be a better term.

This makes sense. I will change interval to step

In the current version, the previous and next buttons don't seem to be working for me. I can tab focus through. This is on Safari.

I'm wondering if we should accommodate track pad interaction, since we are showing some tabs partially and mimicking scroll behavior.

If I use the tab key to focus through the tabs, the last tab has the right side of the focus indicator hidden. If I go the other way, the first tab correctly shows the full focus indicator.

In the current version, the previous and next buttons don't seem to be working for me. I can tab focus through. This is on Safari.

Hmm I just tested with Safari, Chrome, and Firefox. They arrow keys are working in all of them for me. The only difference is in Safari the 'smooth' scroll behavior isn't supported so the tab isn't sliding in or out like in the other browsers. I will push up changes soon based on the review comments and then if the arrow keys are still not working in Safari on your end I will investigate a little deeper why it is working differently on my end vs on your end.

I'm wondering if we should accommodate track pad interaction, since we are showing some tabs partially and mimicking scroll behavior.

This was something Beza and I discussed. Her reasons for not wanting track pad scrolling were that a user could scroll quickly and miss a tab. I could revisit this topic with her though

If I use the tab key to focus through the tabs, the last tab has the right side of the focus indicator hidden. If I go the other way, the first tab correctly shows the full focus indicator.

Fixed in latest commit

I'm wondering if we should accommodate track pad interaction, since we are showing some tabs partially and mimicking scroll behavior.

This was something Beza and I discussed. Her reasons for not wanting track pad scrolling were that a user could scroll quickly and miss a tab. I could revisit this topic with her though

Hmm... How is that different from any scroll situation, where the user can scroll quickly and skip over something? Perhaps the user knows they want the last tab and just want to get to it quickly, without having to step through each one to get there?

I was noticing that when I had a small window size, it was a bit annoying to use the arrows to get back to the first tab after having clicked next through them all to review them.

If I use the tab key to focus through the tabs, the last tab has the right side of the focus indicator hidden. If I go the other way, the first tab correctly shows the full focus indicator.

Fixed in latest commit

For me, Firefox and Safari still have this problem. On Edge, I don't see a problem with the right edge of Tab 12 but I do see it with the left edge of Tab 1 when going backwards.

In the current version, the previous and next buttons don't seem to be working for me. I can tab focus through. This is on Safari.

Hmm I just tested with Safari, Chrome, and Firefox. They arrow keys are working in all of them for me. The only difference is in Safari the 'smooth' scroll behavior isn't supported so the tab isn't sliding in or out like in the other browsers. I will push up changes soon based on the review comments and then if the arrow keys are still not working in Safari on your end I will investigate a little deeper why it is working differently on my end vs on your end.

Edge and Firefox are working for me. Safari still isn't.

Hmm... How is that different from any scroll situation, where the user can scroll quickly and skip over something? Perhaps the user knows they want the last tab and just want to get to it quickly, without having to step through each one to get there?

I was noticing that when I had a small window size, it was a bit annoying to use the arrows to get back to the first tab after having clicked next through them all to review them.

I just chatted with Beza about this. She still feels that scrolling through the tabs is not a good experience. But she said we could allow the option to allow scrolling as a toggle in the theme and for the hpe theme set it so that we don't allow scrolling.

An update on the Safari issue where the arrow keys don't scroll the select:

There is an issue in v15.5 of safari where if a container has overflow: 'hidden' and the scroll behavior is set to 'smooth', scrolling will fail without giving any warnings or errors. (See related issue: https://bugs.webkit.org/show_bug.cgi?id=238497).

A pull request has been merged on the webkit repository to fix this (WebKit/WebKit#1387). This fix is not yet included in the latest version of Safari. The latest version of safari uses webkit v7613.2.7.1.8 the fix is in webkit v7614.1.16.1.

Should we add a work around for this in the meantime? Or go ahead a move forward knowing it should be fixed on Safari's end soon?

I'm still seeing focus indicator clipping on Edge, Firefox, and Safari.

I'm still seeing focus indicator clipping on Edge, Firefox, and Safari.

Looking into it... right now I am only seeing the clipping issue on Safari and just on the last tab

I wonder if our timing calculations are too precise for particular environments and not adaptive enough? I will pull the branch and experiment with them a bit.