Tracking: Stabilize Tabs Blocks

A new Tabs block was added in #69789.

Currently, the following blocks are available only when experimental settings are enabled:

Tabs
- Tabs Menu
  - Tab Menu Item
- Tab Panel
  - Tab

To do

I'm using this tracking issue to list issues that need to be fixed before we can remove the experimental status from these blocks. Please feel free to add more issues if required.

Improve store functionality: Tabs block: Improve store functionality #73229
Restructure to improve maintainability: Feat/core tabs restructure #74412
Improve visual transition and animation: [Tabs block] Visual Transition and Animation #73937
Add Button and Tab Styling options: [Tabs block] Button and Tab Styling options #73932
Tab Content Background Colors [Tabs block] Tab Content Background Colors #73934
Needs Consistent Vertical Tabs Behavior [Tabs block] Needs Consistent Vertical Tabs Behavior #73935
Layout Controls Clarity [Tabs block] Layout Controls Clarity #73936
Improve UX: Tabs block: UX improvement followups #75195
Remove custom state styling controls from Tab Menu Item block: Tabs: Remove custom state styling #75731
Reconsider Tab Menu inner block structure, keeping in mind this comment: Tabs: Restructure Tabs Menu and inner blocks #75954
Handle duplicating tabs (or disable duplicating) Tabs: Handle duplicating tabs #76449 Tabs: Disable Duplicate button #76802
Consider renaming inner blocks to match WCAG Tabs pattern: Tabs: Rename tabs blocks #77341
Keyboard accessibility (nearly done) Tabs block: Keyboard Accessibility #75402
Remove "__experimental": true from blocks

One issue in particular I wanted to resolve: How to handle the custom color attributes for the various tab states in global styles, so users can set these in theme.json more easily as well as in the style book.

I look forward to having the Tabs block fully available in Gutenberg..:)

The Tabs block has a significant number of custom settings that are not common in other blocks. Furthermore, once the block is stabilized, we would be obligated to support these settings forever.

Personally, I would suggest removing all of these custom settings, building a minimal and robust version, and focusing on stabilizing the block.

The Tabs block has a significant number of custom settings that are not common in other blocks. Furthermore, once the block is stabilized, we would be obligated to support these settings forever.

Is fair, in order to offer the easiest editing and styling experience for day to day use by editors much of tabs styling is custom. Ease of editing and transportability was our primary focus, perhaps a good middle ground for more granular styling would be this change:

- Tabs (all tabslist and container styling occurs here, but no tabslist data is saved here it is derived from the individual tab innerblocks)
  - Tab 1: Label ABC
  - Tab 2: Label ABCD
  - Tab 3: Label ABCDE

To

- Tabs (orientation styling still remains here vertical | left/right, etc)
  - Tabs Menu (**locked removal**, tabslist styling occurs here via styling selectors, no tabslist data is saved here, no innerblocks)
  - Tab Panels (**locked removal**)
    - Tab 1: Label ABC
    - Tab 2: Label ABCD
    - Tab 3: Label ABCDE

This way the most important aspect of this structure, the transportability and transformability of individual tab content remains while moving styling more in line with standard blocks. I'm also fine removing the the active and hover color attributes until theres broader support for block states like hover and active.

Let me know if you'd all like us to proceed with this change.

Going to try out this approach today, will submit a new PR if it works out well.

This new approach I think will solve for long term maintenance concerns by getting rid of custom style engine implementations in favor of an approach more in line with core/button, adds greater granular styling, maintains the portability of tab content and hopefully easy of use.

I'll have more to share in a new PR after some additional work on this concept by end of week. I'm also anticipating that this refactor will resolve #73934, #73934, and #73936.

CleanShot.2026-01-06.at.18.12.10.mp4

@mikachan

@mikachan and @t-hamano PR for refactor of tabs to address some of the structural issues and conceptual issues people are having with it. This adheres more to core style supports in lieu of custom style engine implementations. I do think that with this update there's not necessarily a need for a "links" or button" style given they can be created using the built in styling tools (see this screenshot, all of these variations built just using the core layout and styling supports), so I removed them

This PR also flushes out the other styling items for tab menu items like border and box shadow.

Updated #74412 to include a new core/tabs-menu-item template block, this removes the need for utilizing styling hooks like useColorProps and instead we can rely purely on the core style engine. The template block works like core/post-template vis-a-vis block preview and a block context provider to iterate over the template.

CleanShot.2026-01-13.at.12.49.47.mp4

@mikachan

Thanks @mikachan, @jasmussen, @t-hamano and everyone else for helping me get this block across the finish line!

Kudos for the work!

@t-hamano

Hi @t-hamano, what's left to make the Tabs block before removing the experimental flag?

In my opinion, the following issues need to be addressed for now.

Remove redundant context: Tabs: Remove editor-only block context #79848 is under review.
Remove redundant label attributes from tab panel blocks: The code is already written. I plan to submit the PR sometime this week.
Enable adding labels to the tab list. See Tracking: Stabilize Tabs Blocks #73230 (comment)
Adding E2E tests: This should be manageable even after the block is stabilized.

Enable adding labels to the tab list.

I think this is the biggest challenge.

While it is easy to link a tab list to a visual heading via aria-labelledby, where should that heading be placed? If it is placed inside the Tabs block, there needs to be an option to at least change the heading level.

Furthermore, the label for a tab list does not necessarily have to be a heading element. For instance, what if a user wants to use a paragraph block located outside the tab block as the label for the tab list?

It doesn't seem realistic to support all of these. Personally, I think the best approach would be to simply add ariaLabel support, similar to the Accordion, Navigation, and ToC blocks.

@t-hamano

Thanks for laying this out, @t-hamano — good to see the list is this short.

+1 to the simple ariaLabel support as the bar for stabilisation:

The APG tabs pattern itself accepts aria-label when there's no visible label, so this fully satisfies the recommended pattern rather than being a lighter version of it.
It's consistent with how Navigation, Accordion, and Table of Contents already solved the same need, so there's an established precedent for users and for review.
Users who want a visible label can already place a Heading block directly above the Tabs block, so that content is available to everyone in reading order today.

@joedolson's heading field with a visibility toggle sounds like a genuinely nice enhancement, but it raises design questions (heading level, styling, labels living outside the block) that feel like their own project. Could we capture it in a follow-up issue and not gate the experimental-flag removal on it? Since naming a tablist is recommended rather than strictly required, an optional aria-label seems like the right scope for shipping, with the visible-label association as the next improvement.

I'll take a look at the ariaLabel support for the tab. I'm thinking through how we could do the heading support as well, but it is opening a lot of extra complexity due to styling and pushing the experience of adding a heading/paragraph element into the sidebar. I think we should do the first pass of ariaLabel support to the Tab List following conventions then explore heading support.

OK, starting it off with the base level ariaLabel support in #79948, then we can iterate from there.

Update:

Remove redundant context: Tabs: Remove editor-only block context #79848
Enable adding labels to the tab list: Add ariaLabel supports for Tab List Block #79948
Remove redundant label attributes from tab panel blocks: Tabs: Make tab-list the source of truth for tab labels #80031
Fix unstable focus management: See Tabs: Fix active tab switching from a stale inner-block selection #79981 (comment)
Adding E2E tests: This should be manageable even after the block is stabilized.

I'm playing around with #80031 and reordering tabs is attached to rearranging tab panels. I think most people will want to rearrange from the Tab List. Are there plans to add < and > move controls to the Tab List Toolbar to allow reordering Tabs?

I created a new issue:

Tabs: Tabs block overflows horizontally when many tabs are added #80078

I appreciate the effort to make the tabs block as solid as it can be, but can we tackle edge cases like above (adding more than twenty tabs) after the release without experimental flag?

Are there plans to add < and > move controls to the Tab List Toolbar to allow reordering Tabs?

I don't have any plans at the moment, but I think this is certainly a useful feature. Since the grid block already has a precedent of implementing its own mover button, the implementation should not be difficult.

but can we tackle edge cases like above (adding more than twenty tabs) after the release without experimental flag?

The reason we continue development behind an experimental flag is to embrace breaking changes. Once a block is stabilized, it comes with the responsibility of maintaining its functionality and backward compatibility forever. While we aim to stabilize this block before 7.1 Beta 1 next week, we must carefully consider if there are any other potential fixes that could break backward compatibility.

Are there plans to add < and > move controls to the Tab List Toolbar to allow reordering Tabs?

I don't have any plans at the moment, but I think this is certainly a useful feature. Since the grid block already has a precedent of implementing its own mover button, the implementation should not be difficult.

#80031

From the discussion in #80031, it seems like we are not landing that as the current implementation may be safer overall. Have we decided to move forward with removing the experimental flag? Anything else we can do to help with final things before the cutoff?

From the discussion in #80031, it seems like we are not landing that as the current implementation may be safer overall.

Yes, it would be best to put #80031 on hold for now.

Have we decided to move forward with removing the experimental flag? Anything else we can do to help with final things before the cutoff?

We are ready to stabilize this block, and then we can address the minor issues in a follow-up. #80163

Thank you all for your cooperation. We currently have two open PRs, which may also be included in 7.1.

I would like to close this issue, but please open a new issue if you have any feature enhancement suggestions or bug reports.

Navigation Menu

Repository navigation

Tracking: Stabilize Tabs Blocks #73230

To do

40 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking: Stabilize Tabs Blocks #73230

Description

To do

Activity

sethrubenstein commented on Nov 14, 2025

paaljoachim commented on Dec 7, 2025

t-hamano commented on Dec 30, 2025

sethrubenstein commented on Dec 31, 2025

sethrubenstein commented on Jan 6, 2026

sethrubenstein commented on Jan 6, 2026

sethrubenstein commented on Jan 7, 2026

sethrubenstein commented on Jan 13, 2026

sethrubenstein commented on Feb 13, 2026

jasmussen commented on Feb 15, 2026

40 remaining items

t-hamano commented on Jul 7, 2026

iamtakashi commented on Jul 7, 2026

jeryj commented on Jul 7, 2026

jeryj commented on Jul 7, 2026

t-hamano commented on Jul 9, 2026

jeryj commented on Jul 9, 2026

hanneslsm commented on Jul 9, 2026

iamtakashi commented on Jul 9, 2026

t-hamano commented on Jul 10, 2026

t-hamano commented on Jul 10, 2026

jeryj commented on Jul 13, 2026

t-hamano commented on Jul 14, 2026

t-hamano commented on Jul 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions