Tabs: render tabs as Button components by default

[chad1008]

What?

Modifies the Tabs.Tab subcomponent to render as a Button component instead of a plain button html element.

Why?

In an effort to avoid making the Tabs component overly opinionated, we opted for a button element and an optional render prop, so consumers could use a Button if they wanted one for things like icons and tooltips.

At the time everything with this approach seemed good, but I've since noticed that there are some style differences that I'd missed until now. Specifically:

1. Hover effect: Button adds an accent color to the text of tertiary buttons when hovered. The button element rendered by Tabs via Ariakit does not do this.
2. Text alignment: This one is only apparent in cases where the tabs width is expanded, as it is in the List View implementation. In cases like this, where the button is wider than the text it contains, the text becomes centered, rather than left aligned. This is because it lacks the display: inline-flex and subsequent align-items: center provided by the Button component's styles.

How?

A performing a nullish check when passing the render prop down to Ariakit, we can render whatever the consumer wants (including a more detailed Button with an icon and tooltip), and fall back to a standard Button component if no render prop is provided. All of the props passed to Tabs.Tab will flow through the render prop to the default Button component.

Testing Instructions

To begin, apply this diff. It increases the width of the tabs on the default story template

diff --git a/packages/components/src/tabs/stories/index.story.tsx b/packages/components/src/tabs/stories/index.story.tsx
index 0e7ab725e3..f344767668 100644
--- a/packages/components/src/tabs/stories/index.story.tsx
+++ b/packages/components/src/tabs/stories/index.story.tsx
@@ -40,9 +40,15 @@ const Template: StoryFn< typeof Tabs > = ( props ) => {
 	return (
 		<Tabs { ...props }>
 			<Tabs.TabList>
-				<Tabs.Tab tabId="tab1">Tab 1</Tabs.Tab>
-				<Tabs.Tab tabId="tab2">Tab 2</Tabs.Tab>
-				<Tabs.Tab tabId="tab3">Tab 3</Tabs.Tab>
+				<Tabs.Tab tabId="tab1" style={ { width: '33%' } }>
+					Tab 1
+				</Tabs.Tab>
+				<Tabs.Tab tabId="tab2" style={ { width: '33%' } }>
+					Tab 2
+				</Tabs.Tab>
+				<Tabs.Tab tabId="tab3" style={ { width: '33%' } }>
+					Tab 3
+				</Tabs.Tab>
 			</Tabs.TabList>
 			<Tabs.TabPanel tabId="tab1">
 				<p>Selected tab: Tab 1</p>

Testing Instructions

1. Launch Storybook
2. Experiment with the Tabs stories. Confirm that the tabs are properly highlighted when hovered.
3. On the Default story, which has now has wider tabs, confirm that the text is left-aligned.
4. Compared to trunk, confirm there aren't any other visual changes in Storybook
5. Compared to trunk, confirm these styles are now present in the editor (ie. Editor Settings Sidebar, Block Inserter, and in the background color picker for blocks) but there aren't any other unexpected changes.

[github-actions]

Flaky tests detected in ff2f5f0.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7226258203
📝 Reported issues:

• [Flaky Test] should display the "Manage Fonts" icon #56776 in /test/e2e/specs/site-editor/font-library.spec.js

[ciampo]

Code-wise, the changes look good.

cc'ing @mirka around the topic of using Button instead of a vanilla HTML buttonin Tabs — if text alignment and hover color are the only things we are worried about, we could also consider adding those styles to Tabs without using Button at all.

Also cc @WordPress/gutenberg-design for awareness

[paaljoachim]

Let's see if I am in the right place:
https://wordpress.github.io/gutenberg/?path=/docs/components-experimental-tabs--docs

Tab 3.
Text is left aligned.

Not sure what else to do here. I updated the Gutenberg plugin and compared for instance Background color tabs in relation to Storybook.

A sidetrack.
Can we begin the work of setting up a Tabs block? So the user can add tabs to the canvas/document.
Using the Tabs component and various settings similar to other blocks.

[ciampo]

Let's see if I am in the right place: wordpress.github.io/gutenberg/?path=/docs/components-experimental-tabs--docs

Tab 3. Text is left aligned.

Not sure what else to do here. I updated the Gutenberg plugin and compared for instance Background color tabs in relation to Storybook.

The difference in text alignment is noticeable only when the Tab is wider than its text contents — for example, in Storybook, we could manually add a flex: 1 to all Tabs to force then to fill the full width of the screen, which would show how the text is centered:

A sidetrack.
Can we begin the work of setting up a Tabs block? So the user can add tabs to the canvas/document.
Using the Tabs component and various settings similar to other blocks.

I encourage you to discuss this in a separate issue, as the @wordpress/components package and the Tabs component are not mean to be used in editor blocks.

[mirka]

cc'ing @mirka around the topic of using Button instead of a vanilla HTML buttonin Tabs — if text alignment and hover color are the only things we are worried about, we could also consider adding those styles to Tabs without using Button at all.

Yes, I'm usually apprehensive about using a styled component like Button for something that calls for substantially different styling. Any style breakage that could occur from upstream changes are our own responsibility, so it'd be on the Tabs component to have sufficient vizreg tests to catch them. In this case here it sounds like it'd be cheaper to add the required styles without using Button.

[ciampo]

In this case here it sounds like it'd be cheaper to add the required styles without using Button.

Cool, that was my angle too. Let's stick with button and only add necessary styles.

[chad1008]

Thank you both for the input! Closing this PR in favor of #57275, which will add the necessary styles to the button 😄