Try: Improved tabbed sidebar styles #61974
Conversation
|
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. |
DaniGuardiola
requested review from
a team and
ramonjd
and removed request for
a team
DaniGuardiola
added
[Type] Enhancement
|
Size Change: -65 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
To be fair, I prefer how it was before.
From what I understand, we try to keep the tabs occupying all the horizontal space, which made even more visual sense when the X button wasn't there. Even with the X button though, it's OK for them to be wider and occupying more space, there's not much else to do with that space and folks are likely used to have larger inserter category tabs.
This is something @WordPress/gutenberg-design should have a good sense about.
|
Thanks for your attention to detail. There's an ongoing conversation about these changes, maybe @richtabor has more info. |
|
There is a discrepancy between the tabs in the Inserter and the Inspector, but I am cautious to reduce the surface area of the Inserter tabs. Here's the state of the tabs: Current:
Proposed:
|
|
And here's a counter, if we applied the same positioning logic that exists in the Inserter to the Inspector tabs:
Not a formal proposal; an exploration. |
|
Thanks for the visuals, very helpful @richtabor. I think I strongly prefer the first option, personally. |
Yes, and I reported the inconsistencies in #62025 To me, tabs should have the same alignment / layout everywhere. Worth reminding the X close button is candidate to be removed from there, as it breaks the ARIA tabs pattern. See #59013 / #58940 As per @DaniGuardiola proposal in this PR, I support the left alignment option. To me, it doesn't make much sense attempting to have a balanced equal width because the length of the tabs content is not predictable. It may look nice in English, which usually has shorter strings, but it's a bit pointless with longer / uneven strings in other languages. |
|
If the consensus is in favor of the left-aligned instead of balanced-width tabs, I'm fine with that 👍 |
This is the aim of the component I am proposing in #62343 |
…ix/editor-inserter-tabs-styles
DaniGuardiola
changed the title
|
I've updated the PR after @scruffian's work to unify sidebar, and also edited the description to more clearly state the issues and how this PR addresses it. I'd like to seek some consensus around this to hopefully make a decision. cc @WordPress/gutenberg-design @WordPress/gutenberg-components @richtabor @tyxla @afercia |
|
There are also these tabs in the Inspector: 
I agree the behavior should be consistent across. The example above would look quite strange if the icons were aligned left. Looking at the component objectively, centrally aligning the label seems simplest, likely with a prop to specify when the row should fill the container or not.
There could also be a prop to left-align the label/icon, but I'm not entirely convinced it's worth the added complexity. |
Yes, and the Navigation block shows 3 icon-tabs:
I have a solution for that: use text instead of icons by default 🥳 Worth reminding that enabling the 'Show button text labels' preference already switches those tab icons to text, and the alignment is still inconsistent:
|
|
I think those tabs are a different (but definitely related) issue. This PR focuses on the tabbed sidebar layout, currently only present in inserter and list view, but planned for other similar sidebars across the app (see #62343 for full context). I personally feel like what needs to be consistent is this component (tabbed sidebar), and it doesn't feel weird if other tabs like that example have a different layout (especially since it is already quite different by having icon labels instead of text). With that in mind, and if we agree on that, I'm happy to discuss more about those tabs. My hunch is that it might justify a "balanced" variant for icon-based tabs, some notes:
I agree. I think for this "balanced" variant, labels (in this case icons) should indeed be centered.
Agreed. I think the variant should probably revert to the default "left-aligned" layout when the preference is enabled. Feels like it should be implemented at the usage/product level though, and not at the component level, since the preference is a product-level feature. |
I'd agree the inconsistent layout with other tabs isn't a blocker for this PR, which is an improvement. I'd encourage to moev on with this PR as long as there is a follow-up to better consider consistent alignment for all tabs across the entire editor UI. |
There was a problem hiding this comment.
I'm generally in favor of the approach here, since it contributes to a more consistent tabs behavior across the editor and less custom styles and overrides.
However, before we move forward, it would be nice to have a consensus on the design approach, especially as far as those icon-only tabs.
@jameskoster Probably something to add to a hypothetical issue on whether |
|
In terms of design, the question to answer is whether to apply the 'fill' prop in these contexts or not. In other words which is preferred between:
Personally I wouldn't consider that decision a blocker to this PR. |
|
Although for icon-only tabs, they should be centered, the centered text in the fullwide tabs feels awkward. That's either an argument for no fill, or for left-aligned in the tabs by default, with the centered option an exception, or a combination of both. |
|
Ideally we should figure out which options the component should offer and go from there. We know we want fill-with-centered contents for the block settings toolbar so this should be built into the component. The fill-with-left-aligned-contents is dubious imo. It only really seems to exist to align the tab first label with the contents below in the Inserter / Inspector. This is an exception, which is fine, but doesn't really make sense as a component option. To unlock this work I'd propose;
|
|
Thank you for your comments. I like your proposal @jameskoster, though practically speaking if we go for "Update the Inserter tab instance to > Use the default 'hug' layout" then implementing the "fill" variant is not a blocker for this specific PR. I strongly prefer this resolution personally, and it's also the simplest: 
|
|
The issue with merging this first is that there will be an interim where the inserter tabs are narrower, which could be seen as a visual regression. Personally I think it's okay, so long as we address the other issues reasonably quickly, but I'd welcome more thoughts from @WordPress/gutenberg-design. |
|
@jameskoster yes, to be clear I'm proposing that we go with that option ("Update the Inserter tab instance to > Use the default 'hug' layout"), not just temporarily. If so, "fill" is not a blocker here, and tabs being narrower is not a regression but just a "permanent" update. I hope that clarifies what I meant? |
Right, that's the part we need design consensus on. Is the following acceptable: 
It's fine with me, to be honest, but I don't have a full history around the design of this UI. Hopefully @jasmussen can help make this decision. |
|
Sure let's try it. In general we should avoid centered text, so I think that does need followups. But all these pieces need followup, so that wouldn't be a blocker. |
There was a problem hiding this comment.
Glad to see some consensus on the design side 👍
Just confirming, while the text tabs are no longer balanced, the tabs with icons remain balanced, which makes sense and looks good IMHO:
Thanks for the cleanup @DaniGuardiola, looks great 🚀
|
@WordPress/gutenberg-design "fill" implementation #64371 |
I've removed the "balanced" tabs styles, as it overrides the built-in Tabs styles - we're trying to avoid and remove style overrides in the components package for many reasons. @afercia discussed tabs styles here: #62025
If we want these styles to be an option for Tabs, then it should be proposed, discussed and implemented in the Tabs component directly. These styles, though, present some problems beyond aesthetic concerns, notably it could behave badly in other languages since the length of the labels is unpredictable (see @afercia's comment: #61974 (comment))
Before:
chrome_DItpzeDWwt.mp4
After:
Note that this PR also removes a few styles that were completely redundant (basically all but the negative bottom margin).