New Block: Tabs

[deborah86]

What problem does this address?

It is difficult to display a lot of grouped content on a page. The only option is to have all the content display at once on a page because there are no core blocks that hide and show content. A lot of third-party blocks do not follow the standards for tabs.

What is your proposed solution?

The proposed solution is to have a core tab block. See the examples from these websites:

• Tabs | Accessibility Guideliens
• 14 Guidelines For Web Site Tabs Usability
• Tabs, Used Right

[mtias]

See before: #9543

Also related #21584.

[jarekmorawski]

Over the last few weeks, I worked on a design for a Tabs block. It was a high-priority project because without tabs, we can't fully convert existing PHP page templates in WooCommerce into blocks. The new block would also unlock countless customization and layout options for commerce-specific block patterns.

tabs_walkthrough.mov

In the design, each Tab would be a separate block inside the parent Tabs block.

Each tab is a separate Tab block with its own settings: layout (justification, orientation), color, typography, dimensions, and border & shadow.

They only affect the tab’s appearance, not its content. If someone wanted to style the tab content individually, they could add a group block and set up spacings and colors there.

Tab content is displayed as inner blocks and visible in the List View.

Similar to the Buttons block, users can click the + button to add a new tab. They can remove it like any other block by selecting it in the canvas or the List View. Users can edit the tab’s content by selecting it in the canvas, the same as the visitors would on the page. They can also choose a block in the List View.

After selecting a tab, users can type in the name. It will appear not only in the canvas but also in the block details section in the Inspector and in the List View. This will make it easier to identify and manage different tabs.

To add content, users can click the big + button. It’s consistent with how we currently handle empty content in blocks like Group and Columns. Clicking it will open the in-line inserter, which allows users to choose any block and pattern.

Users can go to the Styles tab to edit the tab’s appearance. Clicking the ellipsis menu in the Tab block’s details pane will reveal a state switcher. It allows users to customize the appearance of selected and unselected tabs.

In a way, each tab acts like a template. When the user edits tabs X’s selected state, changes will apply to tabs Y and Z, too.

When the user changes states, another tab immediately takes over to ensure the user never sees the impossible state when no or all tabs are selected. For instance, when I select tab X and change its state to Unselected, tab Y will switch from Unselected to Selected.

Related to #42299 and #57719.

The block would ship with a minimal default style that fully relies on Global Styles and the $currentColor logic. The idea is that it’d work out of the box without any customizations on the user’s side—they should just add it to the canvas, name the tabs, and insert content.

The default style would use the $currentColor for the selected tab’s bottom border and the tab row’s 1-pixel separator. The tab names will inherit from the Text style, though the unselected tab variant will use it at 50% opacity.

This should unlock satisfying customization and acceptable coherence with most visual styles out there, no matter the complexity.

tabs.mov

Builders could use the design options to make further changes. Thanks to support for all staple tools, they’d customize the border size & width, paddings, margins, block spacings, typography, backgrounds, and more.

tabdesigns2.mov

Future considerations

In parallel, I worked on a more robust, future-oriented design that improves usability and adds new functionality. The most important change is icon support. It will allow users to display icons in the tabs and rearrange and customize them as individual inner blocks.

The icon can be added for each block state. It will also work on its own if the user decides not to add tab titles. It will be a separate block enabled when users flip the Show icon toggle in the Styles section. Users could select it to tweak its appearance and position.

There will also be a third tab in the parent block’s Inspector panel. Similar to the Navigation block, it’d display a list of tabs inside. Sometimes, when the screen space is limited, it may be difficult to find the + button to add a tab. The panel will make the tabs available at all times, no matter if there are two or 20 of them.

---

I put a lot of thought into the design and structure of this block, but there's probably plenty of nuance or historical context I've missed. Let me know if you have any thoughts or ideas for improvements!

[Jabe64]

Congratulations @jarekmorawski it looks amazing and very promising 😍

About adding icon support in the future, I think it should be integrated once a real icon block has been added as requested 5 years ago in #16484 and for custom block #51563 API is still needed and is at a standstill since 1 year...

[paaljoachim]

Thank you for your detailed overview @jarekmorawski

It would be great to get design folks to take a closer look at this:
@WordPress/gutenberg-design
@richtabor

[jameskoster]

The mockup looks good to me. Though I wonder what the simplest first step would be. For instance the initial version may not need the icon feature, Inspector list view, or state styling.

Adding icons to buttons is a more holistic issue that we should find a single solution for, and obviously States (#57719) do not exist yet.

[jarekmorawski]

💯 There's a simpler, MVP-friendly version of the design without the extra customization settings (Figma).

obviously States (#57719) do not exist yet.

@jasmussen, @mtias, and I talked about building a version of states as an experiment in the Navigation block
without building out the whole logic/API yet (#42299). Perhaps Tabs could tap into that or become another experiment.

[gziolo]

I'm working on the prototype outside of the Gutenberg repository: a8cteam51/special-projects-blocks-monorepo#12. Thank you @jarekmorawski for sharing all the design ideas and prototypes. Amazing work. I was able to quickly advance the work based on what you shared and it's been a fun exploration thus far!

There will also be a third tab in the parent block’s Inspector panel. Similar to the Navigation block, it’d display a list of tabs inside. Sometimes, when the screen space is limited, it may be difficult to find the + button to add a tab. The panel will make the tabs available at all times, no matter if there are two or 20 of them.

So that would work similarly to the Navigation block. Unfortunately the Go to parent Navigation block behavrio is currently hardcoded in the @wordpress/block-editor package that shows up when navigation to Navigation Item blocks. However, the list group in the inspector controls is available, so that might work at least for the Tabs block.

The icon can be added for each block state. It will also work on its own if the user decides not to add tab titles. It will be a separate block enabled when users flip the Show icon toggle in the Styles section. Users could select it to tweak its appearance and position.

I'm not convinced that the idea of the Icon block is fully compatible with the way the Tab block could be represented. I don't fully understand why the Icon would get so much prominence compared to the tab's title, which would be represented as a regular attribute. In this model, the Tab Icon block is at the same level of nesting as the tab's inner content so the question is what happens when the user starts interacting with these blocks using drag & drop, block movers, etc. It would be way simpler if the icon and title where regular block attributes on the Tab block. The alternative would be having more granular structure:

-- Tabs
  -- Tab
    -- Tab Icon
    -- Tab Title
    -- Tab Content
        -- Paragraph
        -- Image
  -- Another Tab

[gziolo]

Users can go to the Styles tab to edit the tab’s appearance. Clicking the ellipsis menu in the Tab block’s details pane will reveal a state switcher. It allows users to customize the appearance of selected and unselected tabs.

In a way, each tab acts like a template. When the user edits tabs X’s selected state, changes will apply to tabs Y and Z, too.

That part isn't entirely clear to me. Could we start simpler and provide styling settings in the parent Tabs block that would only impact the tabs switcher? In case we have two or more tabs there is always going to be at least one selected and one unselected tab, so that should be enough for users to play with styling.

In particular, this seems like a complex UX when interacting with currently selected Tab block, to put it in the state where the inner block are no longer visible but instead we display inner block from another Tab. This raises the questions like:

• How do we pick the other tab to display? The first one? What if the first one is currently selected? The second one? What if there is only one tab?
• What happens when the block is in "unselected" state, and someone clicks the inner content in List View? Do we put the block again in the "selected" state?

[jarekmorawski]

I don't fully understand why the Icon would get so much prominence compared to the tab's title, which would be represented as a regular attribute.

The main reason is flexibility. It'd be an inner block, which means that users could select it, rearrange it, and customize it just like any other block. I experimented with integrating icon-related settings with the main block, but it felt overwhelming and required additional controls for the icon position (left/right), which felt odd given we let users manipulate other design elements directly.

The alternative would be having more granular structure:

I considered that, but 1) we don't have enough settings to put on the Tab Title block 2) I wanted to stay aligned with other core blocks, like Buttons.

In case we have two or more tabs there is always going to be at least one selected and one unselected tab, so that should be enough for users to play with styling.

That's what I meant. We'd start without the state switcher and see how the UX feels. I added it as a vehicle to customize the appearance of the unselected state.

Imagine that the user selects Tab 1. It's now the selected state. They customize the appearance and save changes.

Now they switch to Tab 2, which is in the selected state. Tab 2 has the same appearance as Tab 1 previously, but now Tab 1 has a different appearance because it's no longer selected.

How would the user change the appearance of Tab 1 when the Tab 1 block is selected? If selecting a block = selecting a tab, it'd be impossible to customize Tab 1.

The state switcher, however imperfect, offers a solution we can test and iterate on.

[richtabor]

I don't think tabs should have a layout panel, and also probably not a third tab in the Inspector for adding tabs.

The third tab UX in the Navigation block is not the best experience and not something we should leverage, especially for a block like tabs which should be easy and intuitive to add. As easy as the details block for example.

Perhaps in the future, but to keep scope down and keep the block as simple (and usable) as possible, I'd omit those.

[gziolo]

I'm wrapping up the week-long exploration of the Tabs block. I shared where I left in a8cteam51/special-projects-blocks-monorepo#12 (comment). I recreated the Example of Tabs with Automatic Activation from ARIA Authoring Practices Guide (APG). This is how it looks in action:

Progress.July.19th.mov

I wanted to exercise how far we are with improving the experience for developers writing custom blocks when they are forced to use only available public APIs. I need to reflect a bit about some of the challenges I encountered. There wasn't anything that would prevent me from achieving the goal, but I had a few hiccups that made it harder to move forward despite my quite extensive knowledge of all the necessary concepts. That said, the block built is a complex one, so maybe that was inevitable.

[creativecoder]

Noting here that I'm working on a tabs block over at #63689. It's set up to be behind an experimental flag, for now, so that we can iterate on the block without worrying about block deprecations.

@jarekmorawski Could I get the SVG icons from the designs for tabs and tab to use when registering the blocks?

[jarekmorawski]

Here they are!

Tabs

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> <path fill-rule="evenodd" clip-rule="evenodd" d="M5.2998 4.8501C4.60945 4.8501 4.0498 5.40974 4.0498 6.1001V10.3501H11.3498V6.1001C11.3498 5.40974 10.7902 4.8501 10.0998 4.8501H5.2998ZM14.2002 10.3501V7.1001H18.5002V10.3501H20.0002V6.8501C20.0002 6.15974 19.4406 5.6001 18.7502 5.6001H13.9502C13.2598 5.6001 12.7002 6.15974 12.7002 6.8501V10.3501H14.2002ZM20 12.6001H4V14.1001H20V12.6001ZM14 17.1001H4V18.6001H14V17.1001Z" fill="#1E1E1E"/> </svg>

Tab

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> <path fill-rule="evenodd" clip-rule="evenodd" d="M5.5498 10.3501V6.3501H9.8498V10.3501H11.3498V6.1001C11.3498 5.40974 10.7902 4.8501 10.0998 4.8501H5.2998C4.60945 4.8501 4.0498 5.40974 4.0498 6.1001V10.3501H5.5498ZM20 12.6001H4V14.1001L20 14.1001V12.6001ZM14 17.1001H4V18.6001H14V17.1001Z" fill="#1E1E1E"/> </svg>

[hanneslsm]

Since this is currently in progress, a question: Would this work as a foundation for a slider block for the future? #43369

[creativecoder]

@hanneslsm I think it's likely there will be some overlap in the technical implementation for a slider block, but I anticipate the slider block would be developed as a separate, independent block, (like how the Accordion block has similarities to the tabs block, but is separate).