Tabs: unify styles and remove overrides #64307

We're in the process of stabilizing the new Tabs component, see #52997

Since it's already been in the wild for some time, there's been enough time for it to be used in multiple places across Gutenberg, and this has surfaced many needs expressed in the form of style overrides. This is helpful as it's information that we can now use to improve the base component - however, we're actively discouraging style overrides as they inevitably result is breakages and wasted developer time down the line, which in turn severely limits the ability for us to evolve the component.

For this reason, there have been conversations across multiple issues and PRs about certain aspects of Tabs going on for a while. In this issue, I intend to enumerate and centralize all these aspects with the following goals:

• Reach decisions on these topics.
• Remove all (ideally) style overrides.
• Make any necessary updates to the Tabs component to reasonably cover its necessary UI needs.

I ask for the help from @WordPress/gutenberg-components and @WordPress/gutenberg-design to reach good compromises here and unblock this work. I intend to leave enough time for everyone to leave their thoughts and to test related changes as this effort evolves to reflect the latest decisions or explorations. That said, we need to get this wrapped up to unblock the rest of the work.

Feel free to chime in, and please use numbers to clearly refer to each of the discussions you intend to contribute to. Thank you!

Design aspects of Tabs being discussed

I'm adding a quick summary of each discussion as well as a "current status" or "resolution" summary to provide visibility. Keep in mind that I might have missed something or gotten something wrong - I'm only human. Just let me know and I'll correct it.

These summaries also have the purpose of clearly expressing the current direction to give everyone a fair chance to reply now, before they are considered resolved and closed, at least for the foreseeable future.

1. Improve display of many tabs in narrow containers #64093

   Sometimes there can be too many tabs and they don't fit in the container. In this discussion, several ideas are compared, including scroll and wrapping strategies.

   Status: 🔴 open

   Current state: scrolling implemented in Tabs: tweak sizing and overflow behavior of TabList #64371, need to further experiment with more clear indicators of overflow and enhanced interaction patterns.

2. Try: Improved tabbed sidebar styles #61974

   There was a style override in sidebars that expanded the size of the tab container and made tabs expand as well in equal sizes ("fill" style). The above PR removed that override, and contained general discussion of "fill" vs "hug" styles, as well as (if "fill" is implemented natively) whether the labels should be centered or left-aligned.

   Status: ✅ resolved

   Resolution: achieved consensus on the necessity of a "fill-with-centered-label" style (necessary at least for icon labels). Implemented a way to achieve both "hug" and "fill" layouts without variants, instead tablists are "hug" by default, and the user can tweak the width property and which makes tabs adapt in a "fill" manner. This was implemented in Tabs: tweak sizing and overflow behavior of TabList #64371 which includes an interactive Storybook story to set how this works (video in the description).

3. Tabs: add vertical indicator animation #62879 (comment) (vertical indicator styles)

   After the implementation of a vertical indicator in Tabs, we realized that there is disparity between multiple instances of this indicator's styles.

   Status: ✅ resolved

   Resolution: vertical styles in general were discussed, unified and updated in Tabs: unify vertical tabs styles #65387.

4. Tabs: select tab id and visual highlight are out of sync when removing tab #65576

   An outstanding bug of the indicator.

   Status: 🔴 open

   Current state: fix pending.