Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: New Block.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @davewhitley, @deborah86.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: davewhitley, deborah86.

Co-authored-by: sethrubenstein <smrubenstein@git.wordpress.org>
Co-authored-by: Infinite-Null <ankitkumarshah@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: alexstine <alexstine@git.wordpress.org>
Co-authored-by: mikachan <mikachan@git.wordpress.org>
Co-authored-by: luisherranz <luisherranz@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>
Co-authored-by: jarekmorawski <jarekmorawski@git.wordpress.org>
Co-authored-by: Jabe64 <jabe@git.wordpress.org>
Co-authored-by: paaljoachim <paaljoachim@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: creativecoder <grantmkin@git.wordpress.org>
Co-authored-by: hanneslsm <hanneslsm@git.wordpress.org>

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

Alright alright alright, all tests (minus 2 that I'm pretty sure are unrelated to my PR) have passed 😁 and I am ready for people to start reviewing and offer feedback on the new core/tabs and core/tab blocks.

Thanks for contributing, @sethrubenstein!

An overhaul of tab editing has been implemented. A Slotfill (thanks @fabiankaegy for the idea) is now used to manage the tabs list and individual tab items.

What was an initial version of this? My worry here is that SlotFills are public APIs by default, so anyone who knows their name (and can read source code) can add anything to them. This can break the tab block or prevent future iterations. Similar public APIs limit our ability to make significant changes to the UI.

@Mamaduka you can view my original comment here: #63689 (comment)

Are those slot fills when implemented that way accessible to anyone? I though they had to actually go through exported components in order to be connected properly 🤔

Are those slot fills when implemented that way accessible to anyone?

Technically, yes. If you know the name key, you can inject your components by using the Fill component. The core uses Symbol for some private/experimental SlotFills to avoid leaking the APIs.

Example:

I've yet to test this; I was just curious about design decisions. I think it's an interesting challenge, and I'm looking forward to seeing the final result :)

P.S. This also reminded me of the Tabs API designs by UI libraries. Example: https://ariakit.org/components/tab.

Thanks for contributing, @sethrubenstein!

An overhaul of tab editing has been implemented. A Slotfill (thanks @fabiankaegy for the idea) is now used to manage the tabs list and individual tab items.

What was an initial version of this? My worry here is that SlotFills are public APIs by default, so anyone who knows their name (and can read source code) can add anything to them. This can break the tab block or prevent future iterations. Similar public APIs limit our ability to make significant changes to the UI.

That is an interesting point, I hadn't thought of that. I'll try the Symbol method to see if I can get that to work well and get back to you all later in the week.

That SlotFill key scoping solution worked without issue @Mamaduka, I'll keep that one in mind whenever I need to make a "private" SlotFill.

Also, updated the icons so they're in @wordpress/icons proper @Infinite-Null

@sethrubenstein Not really involved these days in WordPress but every now and then, I glance over the PRs.

In the editor, unfortunately due to the Slotfill nature of selecting and activating tabs this is currently not possible.

If this PR is starting off by admitting that keyboard only users will not have access in the editor, maybe this type of UI doesn't belong in core. Just my two sense without testing everything. Maybe you've thought of a way around this.

@alexstine Yeah this is something I definitely would like some feedback and testing on. At first I thought my keyboard handlers on the parent block were the only way to go, and they were not firing because of losing focus when I tried to navigate between tabs so I pulled them. I just went back in and changed out the <a/> tab link elements for <button/> elements and moved my handlers for when the user select’s the tab there and this is surprisingly working pretty well.

I’m debating changing the frontend elements to be buttons instead of a tags as well if it were not for the href signal? Anyone else have another suggestions on keyboard handlers that should be present that currently are not?

Seems like the tabs on the front end really don't work with screen readers. Needs to be adjusted to follow spec.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tab_role#example

Back-end more or less works now but I don't have time to inspect the code at the moment to see if improvements can be made.

FYI @afercia @joedolson

@alexstine Thanks, I'll get that changed sometime tomorrow.

I had the wrong aria-role and some unneeded structure, fixed.

@sethrubenstein This is testing much better now. Nice.

@sethrubenstein Hi! I'm excited about your PR. I'd be glad to review the design of this, once the conflicts are resolved.

@davewhitley Thanks! I'll get this merge conflicts resolved on Monday and ping you.

@davewhitley Merge conflicts are now resolved.

I have an update regarding some structural changes I'm making to the iAPI implementation to make tabs more extensible for developers. Currently, I'm traversing parsed_block['innerBlocks'] to build the list of tabs and markup, but I'm moving away from that approach. Instead, I'll be relying on iAPI global state and iAPI templates.

Each tab block will add its own values, such as id and label, to the core/tabs global state. This change may not necessarily reduce code complexity; in fact, it could increase it, as I'm also introducing a render_block_data function to generate a unique ID for the tabs wrapper block. This ID will then be passed down to each tab block via block context.

The main reason for this change is to enhance extensibility. Now, the interior tab block will generate the tabs list instead of the tabs block itself. This method allows developers to envision new interior sections for tabs while simplifying interaction with the tabs list. All that's necessary for an interior section is to apply some code like this:

<?php
$tag_processor = new WP_HTML_Tag_Processor( $content );
$tab_id               = wp_unique_id( 'tab__' );
$state                 = wp_interactivity_state( 'prc-block/tabs', array() );
$state[ $block->context['tabs/id'] ][] = array(
	'id'       => $tab_id,
	'label' => $attributes['label'],
	'href'  => '#' . $tab_id,
);
wp_interactivity_state( 'prc-block/tabs', $state );

$tag_processor->set_attribute(
	'data-wp-context',
	wp_json_encode(
		array(
			'tab' => array(
				'id' => 'tab__' . $tab_id,
			),
		)
	)
);
$tag_processor->set_attribute( 'data-wp-bind--hidden', '!state.isActiveTab' );
$tag_processor->set_attribute( 'data-wp-bind--tabindex', 'state.tabIndexAttribute' );
return $tag_processor->get_updated_html();

To accomplish the following requirements: 1.) add their respective id, label, href link into core/tabs global state, and 2.) wrap their section with tab.id context, this is because the iAPI store has functionality that utilizes this pattern:

const { tab } = getContext();
const id = tab?.id;

For use in both the tabslist template and the tab sections themselves.

These changes are wrapped up in our block library at the moment, I should have time to port them into this PR after WCUS.

Thanks for picking this up! I'd be happy to review this when you're ready.

Using Gutenberg Run, I ran into an issue. Hard to to explain, but pretty soon into testing, the focus would repeatedly move away from the element that I clicked on. Notice how the insert button is flashing (that's not just the video):

So far this looks like a great and much needed addition. At a minimum though, I think there should be 2 more styles of tabs that are selectable from the sidebar. There should be button style and plain link style:

(instead of dropdown, it would say "tabs")

The tab style is actually not used very often in web design today; it's usually a plain link style or button style:

It would be great to get these options out of the box along with settings to set background color, border color, etc.!

I'm moving away from that approach. Instead, I'll be relying on iAPI global state and iAPI templates.

Is it your intention to do something similar to this?

$tab_id = wp_unique_id( 'tab__' );

We should look at what happens when there is a client-side navigation to make sure this block is compatible. Maybe we should use getServerState() to replace the ids, although depending on how you structure the state, it could be reset unintentionally, for example, by changing the tab that the user has open at that moment. So maybe we should try to make this id stable across renders, similar to the Query block one, which is saved as an attribute.

Anyway, just something to keep in mind as you move forward with that implementation.

@luisherranz Good point on the unique id, I'll double check that on client side navigation. Otherwise I'll build a more reproducible id from the tab label slug. Expect another push on this PR with changes to how I'm currently handling the tabs list shortly after WCUS.