WordPress
Updating TabPanel
Now that TabPanel usage is on the verge of becoming a little more widespead across the Editor (see https://github.com/WordPress/gutenberg/issues/38277#issuecomment-1170082093 and https://github.com/WordPress/gutenberg/pull/41937), it's a good time to consider some aspects of the component design:
Additional to the examples listed above, the most prominent instances of this component paint a border beneath the tabs:
| Inserter | Inspector |
|---|---|
 |
 |
However, the default styling of the component does not include this border. Adding this same style manually across multiple instances is obviously not ideal.
With these new applications we also find situations where Tabs exist within the panels of other Tabs, and in other panels like the color picker. So a question arises about whether there should be a style variant that resembles hierarchy.
Lastly we might consider the layout as well. In particular; should tabs fill their container horizontally? How can we make the panel padding elegantly match the parent container padding, or should the panel padding always be static?
TLDR:
It would be nice if we can avoid ad hoc style overrides when using TabPanel.
- Should there be a border beneath the tabs as a default?
- Should tabs fill their container horizontally, ignoring padding?
- Should tab panel padding be static, or be context aware so that it can match its parent?
- Should there be a style variant for TabPanels nested within TabPanels, IE secondary tabs? If so, when exactly should this be applied, and can it be handled programatically?
cc @WordPress/gutenberg-design
Another consideration; when a tab panel is the first child in an element that has padding it can look a little strange:
It would be good to explore options whereby the tabpanel position can be offset without affecting the targetable area.
I think we can use the designs from https://github.com/WordPress/gutenberg/issues/41904#issuecomment-1165341454 here.
And to answer my own questions in the OP:
Should there be a border beneath the tabs as a default?
I think so. Given the active indicator we use the tab UI looks a bit unfinished without it. We'll need to update current implementations where the border is added ad hoc (Inspector and Inserter).
Should tabs fill their container horizontally, ignoring padding?
It would be nice if there was a way to do this in a context-aware manner, but I appreciate that might be difficult. Alternatively perhaps we can make it possible to pass a spacing preset to the tabpanel and use that as an offset (negative margin).
Should tab panel padding be static, or be context aware so that it can match its parent?
We might do something similar to the previous point – if the tabpanel margin is offset, offer a way to add the offset to the padding.
Should there be a style variant for TabPanels nested within TabPanels, IE secondary tabs? If so, when exactly should this be applied, and can it be handled programatically?
Tabs within tabs are uncommon (not sure we have any instances of this in the UI currently), so we probably don't need to prioritise this.
This may be edge cases, but I'll mention #33108 because it may be a good idea to consider cases where the tab panel has long text.
That's a good consideration, thanks. I would be happy to discuss the newly added Setting / Styles tab at the same time.
Double-tabbing is also a problem, but I am concerned that in the case of a block with many items, there is a high possibility that users will not be able to see the tabs when loading the page and will get lost in the operation. At least I was lost in the operation even though I knew it was tabbed.
Perhaps it would be better to be fixed at the top when scrolled.
I would be happy to discuss the newly added Setting / Styles tab at the same time.
Perhaps it would be better to be fixed at the top when scrolled.
Since tablists aren't really designed to be stacked vertically, we should ideally reconsider whether it's a good idea to nest tabs in the first place. Has this problem been discussed before, @jameskoster?
Another way around it could be to make the nested tabpanel a separate scrolling container, but that's probably not a silver bullet either:
Making the settings/appearance tabs sticky is worth exploring, similar to blocks/patterns/media in the Inserter. I don't know that it needs to be a specific prop on the component though, it feels like something to be treated more contextually.
I agree that visually stacked tablists look a bit awkward. I haven't seen any explorations around how to address that yet.
Thank you for considering my opinion. As the number of things that can be done increases, it is inevitable that the UI will become more complex. Personally, I feel that the UI is becoming more and more similar to Figma.
However, I would like to avoid the fact that the functions are buried and users do not notice them. It may be desirable to consider such complex UI design on Figma.
Another way around it could be to make the nested tabpanel a separate scrolling container, but that's probably not a silver bullet either
I misread this to mean individually scrolling sections within the container. But if the container itself scrolled that might work. It's worth a try imo.
Let's focus labels a bit by having feedback on this not need design - I think that is more appropriate.
