Fix: Tabs block: Start with empty tab labels with placeholders

[hbhalodia]

What?

Closes #80957

Why?

• PR removes the default labels for tablist from panel, and adds the placeholder with an attribute.

How?

• Updated the tabs block to include the placeholders instead of labels on default tabs addition.

Testing Instructions

1. Open post/page.
2. Add the tabs block.
3. You will see the tab list with placeholder, Tab Title instead of Tab label.
4. For patterns, template - pass placeholder attribute and use that pattern, you would notice the placeholder is what you have added for pattern.

Testing Instructions for Keyboard

• None

Use of AI Tools

• Claude Code, Opus 5.
• For drafting implementation, spec test. Implementation was reviewed by me.
• For detailed description of PR which is shown below.

---

AI Summary

What?

Closes #80957

Tabs now start out untitled. Instead of inserting two tabs literally labelled "Tab", the Tabs block inserts two tabs with an empty label that render a "Tab title" placeholder in the editor. core/tab-panel also gains an optional placeholder attribute so patterns and templates can replace that prompt with something contextual, e.g. "Ingredient group" or "Question".

Why?

The hardcoded __( 'Tab' ) default meant every new tab arrived pre-filled with a word nobody wants to keep:

• Authors had to select and delete "Tab" before typing a real title, on every tab.
• Publishing without editing shipped a row of tabs all named "Tab" — meaningless to readers and to screen reader users.
• It was inconsistent with the rest of the library. Paragraph, Heading, List Item, and Details all start empty and prompt for content rather than pre-filling it.

The Tab List block already had a __( 'Tab title' ) placeholder in place — it was simply never visible, because the label was never empty. This change lets that placeholder do its job, and adds the pattern-level override suggested in the issue.

How?

File	Change
packages/block-library/src/tab-panels/edit.js	Insertion template is now [ [ 'core/tab-panel' ], [ 'core/tab-panel' ] ] — the label: __( 'Tab' ) defaults are gone
packages/block-library/src/tabs/use-tab-actions.js	insertTab creates core/tab-panel with no attributes, so tabs added via the toolbar or Enter are also untitled
packages/block-library/src/tab-panel/block.json	New optional placeholder string attribute
packages/block-library/src/tab-list/edit.js	Each tab's RichText uses its panel's placeholder, falling back to __( 'Tab title' )
packages/block-library/src/tab-panel/README.md	Regenerated via npm run docs:blocks-detail
packages/block-library/CHANGELOG.md	Changelog entry
test/e2e/specs/editor/blocks/tabs.spec.js	New Tab labels describe block, 3 tests

Implementation notes:

• The placeholder attribute lives on core/tab-panel, next to label. The label is a tab-panel attribute that Tab List renders on its behalf, so its placeholder belongs in the same place. This matches the existing placeholder attribute convention in Paragraph, Heading, List Item, Details, and Post Title.
• It is editor-only. tab-list/save.js passes no placeholder to RichText.Content, so nothing is added to the saved markup or the front end.
• It is per panel, and nothing propagates it. Each core/tab-panel declares its own prompt; a tab the author adds afterwards falls back to "Tab title". Making added tabs inherit a sibling's prompt would need the attribute to move up to core/tabs/core/tab-list and reach the labels through block context — deliberately out of scope here.
• No deprecation or migration needed. label already defaulted to ""; only the values written at insertion time changed. Existing posts parse and serialize byte-for-byte identically, and placeholder has no default, so it is absent from markup unless a pattern sets it.

Testing Instructions

1. Create a new post and insert a Tabs block.

2. Both tabs are empty and show a greyed-out "Tab title" prompt. Open the code editor (Ctrl+Shift+Alt+M) and confirm the tab panels carry no label attribute.

3. Click the first tab and type a title. The placeholder disappears on that tab only; the second tab still prompts.

4. With a tab selected, click Add tab in the block toolbar. The new tab is empty and shows the prompt. Same when pressing Enter at the end of an existing tab label.

5. Confirm no regression on existing content: paste the markup below into the code editor, switch back to the visual editor, and check the tabs still read "Tab 1" / "Tab 2" with no block validation warning.

   <!-- wp:tabs -->
   <div class="wp-block-tabs"><!-- wp:tab-list -->
   <div role="tablist" class="wp-block-tab-list"><button type="button" role="tab">Tab 1</button><button type="button" role="tab">Tab 2</button></div>
   <!-- /wp:tab-list -->
   
   <!-- wp:tab-panels -->
   <div class="wp-block-tab-panels"><!-- wp:tab-panel {"label":"Tab 1"} -->
   <section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
   <p>Panel 1</p>
   <!-- /wp:paragraph --></section>
   <!-- /wp:tab-panel -->
   
   <!-- wp:tab-panel {"label":"Tab 2"} -->
   <section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
   <p>Panel 2</p>
   <!-- /wp:paragraph --></section>
   <!-- /wp:tab-panel --></div>
   <!-- /wp:tab-panels --></div>
   <!-- /wp:tabs -->

6. Publish a post with untitled tabs and view the front end. The tab buttons render empty — expected, and the same as publishing an empty Heading. Tab switching still works.

Testing the placeholder override

A. Quickest check — no PHP required

1. New post → Options (⋮) → Code editor.
2. Paste this and switch back to the Visual editor:

<!-- wp:tabs -->
<div class="wp-block-tabs"><!-- wp:tab-list -->
<div role="tablist" class="wp-block-tab-list"><button type="button" role="tab"></button><button type="button" role="tab"></button></div>
<!-- /wp:tab-list -->

<!-- wp:tab-panels -->
<div class="wp-block-tab-panels"><!-- wp:tab-panel {"placeholder":"Ingredient group"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel -->

<!-- wp:tab-panel {"placeholder":"Cooking step"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel --></div>
<!-- /wp:tab-panels --></div>
<!-- /wp:tabs -->

Expected: the first tab prompts "Ingredient group", the second "Cooking step" — placeholders are per panel and can differ. Typing in either replaces only that tab's prompt. Add a third tab from the toolbar and it falls back to "Tab title".

B. Testing from a pattern

As a theme pattern — drop this in the active block theme as patterns/tabs-placeholder-test.php:

<?php
/**
 * Title: Placeholder test tabs
 * Slug: test/tabs-placeholder
 * Categories: featured
 */
?>
<!-- wp:tabs -->
<div class="wp-block-tabs"><!-- wp:tab-list -->
<div role="tablist" class="wp-block-tab-list"><button type="button" role="tab"></button><button type="button" role="tab"></button></div>
<!-- /wp:tab-list -->

<!-- wp:tab-panels -->
<div class="wp-block-tab-panels"><!-- wp:tab-panel {"placeholder":"Ingredient group"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph {"placeholder":"List the ingredients"} -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel -->

<!-- wp:tab-panel {"placeholder":"Ingredient group"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel --></div>
<!-- /wp:tab-panels --></div>
<!-- /wp:tabs -->

Or as a plugin — drop this in wp-content/mu-plugins/tabs-placeholder-test.php (single-quoted heredoc keeps the markup verbatim):

<?php
/**
 * Plugin Name: Tabs placeholder test
 */
add_action(
	'init',
	static function () {
		register_block_pattern(
			'test/tabs-placeholder',
			array(
				'title'      => 'Placeholder test tabs',
				'categories' => array( 'featured' ),
				'content'    => <<<'HTML'
<!-- wp:tabs -->
<div class="wp-block-tabs"><!-- wp:tab-list -->
<div role="tablist" class="wp-block-tab-list"><button type="button" role="tab"></button><button type="button" role="tab"></button></div>
<!-- /wp:tab-list -->

<!-- wp:tab-panels -->
<div class="wp-block-tab-panels"><!-- wp:tab-panel {"placeholder":"Ingredient group"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel -->

<!-- wp:tab-panel {"placeholder":"Ingredient group"} -->
<section role="tabpanel" tabindex="0" class="wp-block-tab-panel"><!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph --></section>
<!-- /wp:tab-panel --></div>
<!-- /wp:tab-panels --></div>
<!-- /wp:tabs -->
HTML,
			)
		);
	}
);

Steps: open the inserter → Patterns → Featured → insert "Placeholder test tabs".

Expected: both tabs prompt "Ingredient group" instead of "Tab title". The pattern preview in the inserter shows the prompts too. Nothing appears in the saved markup for the placeholder beyond the attribute itself, and the front end renders empty buttons until the author types.

Keep the two empty <button type="button" role="tab"></button> elements in the Tab List markup — that saved markup is what the front end renders, and useTabListItemsSync refills it from the panel labels once the author types.

C. Testing from a block template

Post type template — wp-content/mu-plugins/tabs-template-test.php:

<?php
/**
 * Plugin Name: Tabs template test
 */
add_action(
	'init',
	static function () {
		register_post_type(
			'placeholder_test',
			array(
				'label'        => 'Placeholder tests',
				'public'       => true,
				'show_in_rest' => true,
				'supports'     => array( 'title', 'editor' ),
				'template'     => array(
					array(
						'core/tabs',
						array(),
						array(
							array( 'core/tab-list' ),
							array(
								'core/tab-panels',
								array(),
								array(
									array( 'core/tab-panel', array( 'placeholder' => 'Question' ) ),
									array( 'core/tab-panel', array( 'placeholder' => 'Question' ) ),
								),
							),
						),
					),
				),
			)
		);
	}
);

Steps: go to Placeholder tests → Add New.

Expected: the Tabs block is pre-inserted with two tabs prompting "Question".

JS equivalent for a custom block's InnerBlocks template or a block variation:

const TEMPLATE = [
	[
		'core/tabs',
		{},
		[
			[ 'core/tab-list' ],
			[
				'core/tab-panels',
				{},
				[
					[ 'core/tab-panel', { placeholder: __( 'Question' ) } ],
					[ 'core/tab-panel', { placeholder: __( 'Question' ) } ],
				],
			],
		],
	],
];

registerBlockVariation( 'core/tabs', {
	name: 'faq-tabs',
	title: __( 'FAQ tabs' ),
	innerBlocks: [
		[ 'core/tab-list' ],
		[
			'core/tab-panels',
			{},
			[
				[ 'core/tab-panel', { placeholder: __( 'Question' ) } ],
				[ 'core/tab-panel', { placeholder: __( 'Question' ) } ],
			],
		],
	],
} );

Testing Instructions for Keyboard

1. Insert a Tabs block with the keyboard (/tabs then Enter).
2. Focus lands in the first tab label. It is empty, and a screen reader announces the placeholder — RichText falls back to the placeholder for the editable's aria-label when no explicit label is set, so an untitled tab announces "Tab title" (or the pattern's custom prompt) rather than nothing.
3. Type a title, press End then Enter — a new untitled tab is added and focused, announcing the placeholder.
4. Press Backspace on the now-empty label to remove that tab; focus moves to the adjacent tab.
5. Arrow left/right at the label edges to move the caret between tabs and confirm the matching panel activates.

Automated tests

npm run test:e2e -- test/e2e/specs/editor/blocks/tabs.spec.js

The new Tab labels describe block covers:

• tabs start empty and prompt for a title,
• a panel's placeholder attribute overrides the prompt,
• tabs added from the toolbar stay empty and prompt.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: hanneslsm <hanneslsm@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Thanks for the PR.

I agree with starting from an empty tab label, but I'm not sure if customizable placeholders are really needed. For now, I think we should focus only on starting with an empty tab label in this PR and backport it to 7.1. What do you think?

Another point is that we need to clarify whether empty tab labels should apply not only when adding a new tab but also when inserting a block.

cc @hanneslsm @Mamaduka

[hbhalodia]

I agree with starting from an empty tab label, but I'm not sure if customizable placeholders are really needed. For now, I think we should focus only on starting with an empty tab label in this PR and backport it to 7.1. What do you think?

I guess it would be fine, we can create an enhancement ticket for customizable placeholder and limit this to only start with empty label if we need to ship to 7.1. Based on overall descision, I would remove it from PR and update the PR description as well.

Another point is that we need to clarify whether empty tab labels should apply not only when adding a new tab but also when inserting a block.

Can you clarify on this, I see after the testing, When adding the tabs block the labels are not added, instead placeholders are there, and also when adding a tab, the placeholder is added.

Thanks,

[t-hamano]

Another point is that we need to clarify whether empty tab labels should apply not only when adding a new tab but also when inserting a block.

Can you clarify on this, I see after the testing, When adding the tabs block the labels are not added, instead placeholders are there, and also when adding a tab, the placeholder is added.

This PR currently works like this.

insert-without-default-label.mp4

I thought it was supposed to work like this.

insert-with-default-label.mp4

I don't have a strong opinion on which approach is better, but after looking at this PR, I'm starting to think that always adding an empty label might make more sense.

[hanneslsm]

I agree with starting from an empty tab label, but I'm not sure if customizable placeholders are really needed. For now, I think we should focus only on starting with an empty tab label in this PR and backport it to 7.1. What do you think?

A customizable placeholder is currently not highest priority, but it'd be a good enhancement nonetheless. I'd probably change the "tab title" placeholder in some of my patterns to "Feature title" oder "Number".

Another point is that we need to clarify whether empty tab labels should apply not only when adding a new tab but also when inserting a block.

Always empty is good IMO. Everyone will change the prefilled “Tab” text anyway, so we might as well leave it empty from the start.

[t-hamano]

So, let's adopt an approach that starts from empty. Shall we remove the customizable placeholder attributes for now and backport this PR to 7.1?

[t-hamano]

Looks good from my end.

@Mamaduka @hanneslsm, What are your thoughts on backporting this to 7.1?

Update: I noticed the 👍 in #81009 (comment). Let's backport it to 7.1.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 156a13447c91cb3d6a12b507ee75df0592f2b88b

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

@hbhalodia, do you have the bandwidth to manually backport this PR to 7.1? It should likely only involve resolving changelog file conflicts 👍

[hbhalodia]

Hi @t-hamano, I have created a backport PR - #81197, Let me know if that sounds good?