Try: Remove Tab (Tab list item) block #77439
Conversation
|
Size Change: -733 B (-0.01%) Total Size: 8.46 MB 📦 View Changed
|
|
Flaky tests detected in ffa2219. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27316480276
|
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
c1582fb to
ed353e2
Compare
b2c0b14 to
5842bef
Compare
5842bef to
97c311a
Compare
97c311a to
22d2bb7
Compare
|
@t-hamano, will this change break the contents that use the current experimental tabs block? |
That's right. The reason we are keeping this block in an experimental status is to make disruptive changes like this PR. |
|
That's fair. Do you have any idea when the block will officially launch? |
|
I very much endorse this PR, it works well in my testing, and makes the block substantially easier to interact with. It even simplifies the styling aspect, avoiding the need to clone styles from one tab to the other. The downside—the theoretical inability to style individual tabs individually—feels like a valid tradeoff to make: there's room for plugin-tab-blocks that offer such a level of customisation, as it's a level that doesn't feel like it belongs in core. Is there anything I can do to help this PR ship? |
|
Thanks for the feedback!
That's right. Another advantage is that if active tab styling is supported via "State" in the future, styling can be simplified. One of my ideas is to support "attribute" states in the future, in addition to the viewport and pseudo-states. This means something like the following: tab-list.mp4I'm thinking this approach might also be useful for applying styles when the Details block is opened (
One thing we need to decide is whether to remove the |
|
Love it. Keep in mind Navigation menu active state too! I think that may already be planned (CC: @MaggieCabrera), and we can unify the approach here.
If it hasn't been published yet in the library, yes, let's remove. The SVG values are around, they're easy to resurrect if we need them, and I always defer to starting with less then re-adding if necessary. |
The Tab block was removed, and it was the only consumer of the `tab` icon. Drop the icon's source SVG and manifest entry, regenerate the library, and note the breaking change in the changelog. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Rendering RichText with tagName="button" made the editable element a native button, which consumes the Space key for activation and prevents inserting spaces in the label. Wrap a tagName="span" RichText inside the button instead, matching the prior structure the focus logic already assumes (it queries the button for a contenteditable child). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
The Tab block was removed, so regenerate the docs manifest to remove its now-dangling reference to the deleted tab README. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
@mikachan @sethrubenstein @carolinan, I welcome any feedback on this PR. |
jasmussen
left a comment
There was a problem hiding this comment.
From an experience and simplicity POV, this feels like the right path to me and a much leaner user experience.
|
Let's try this PR. Since this block is still in experimental status, we can change the approach later if necessary. |
Part of #73230
What?
This PR attempts to completely remove the 'Tab' block (the tab button block that lives inside 'Tab List') and instead manage the tab count and labels as a
tabsattribute on the Tab List block, rendering them as button elements rather than blocks.Why?
The main issue is that when styling individual Tab buttons at the block instance level, you either have to style each Tab button individually or select them all beforehand. Furthermore, you need to apply the styles every time you add a tab. This problem becomes even more complex if you want to control the styling of the active Tab button using
@currentin the future.A similar issue occurs with Tab Panels, but many users would likely want to style the Tab buttons rather than the panel itself.
How?
This approach has its advantages and disadvantages. Personally, I believe the advantages outweigh the disadvantages, but I would like to hear your thoughts.
Testing Instructions
Use of AI Tools
This PR was authored with Claude Code (claude-opus-4-6). All changes were reviewed and approved by the contributor.