-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try tabs instead of segmented control for switching between solid/gradient in color panels #41937
Changes from 8 commits
33784ae
504ec42
7859cef
8d1a7ff
733ae8b
4718182
a48c69b
1b7a34a
461c0f9
7b566da
587692c
b77b4df
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -42,6 +42,16 @@ | |
|
||
.block-editor-panel-color-gradient-settings__dropdown-content .components-popover__content { | ||
width: $sidebar-width; | ||
|
||
.block-editor-color-gradient-control__tabs { | ||
margin-top: - $grid-unit-10; | ||
margin-left: - $grid-unit-10; | ||
margin-right: - $grid-unit-10; | ||
} | ||
|
||
.block-editor-color-gradient-control__tab-panel { | ||
padding: $grid-unit-10; | ||
} | ||
} | ||
|
||
|
||
|
@@ -100,3 +110,7 @@ | |
.block-editor-panel-color-gradient-settings__dropdown { | ||
width: 100%; | ||
} | ||
|
||
.block-editor-color-gradient-control__tab-panel { | ||
border-top: 1px solid $gray-300; | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW, after working on this PR, I'm now a little apprehensive about adding in this ad hoc border. The Global Styles ▸ Colors menu already contains several tabbed color panels that have different implementations, easily leading to style fragmentation. See also #41976 which seems to have landed recently. Your call, but it might be better to leave the border off for now and address the border issue in a separate PR. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -75,7 +75,7 @@ function ScreenLinkColor( { name } ) { | |
) } | ||
/> | ||
|
||
<TabPanel className="my-tab-panel" tabs={ tabs }> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🧹 Removed some copypasta here |
||
<TabPanel tabs={ tabs }> | ||
{ ( tab ) => { | ||
const pseudoSelectorConfig = | ||
pseudoStates[ tab.name ] ?? null; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there's a better way to make sure that the Tabs fill the whole width of the sidebar — what about removing the padding from
.edit-site-screen-background-color__control
and adding it back only to the tab panel's contents?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose avoiding negative values has some merit, but both implementations would still be exposed to the same risk, no? Just trying to fully understand the implications :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, there isn't anything wrong with negative margins. In this case, it's more about introducing custom style overrides of the
TabPanel
component (that implicitly relies on the fact that the popover's content has a padding of$grid-unit-10
px).Specifically to this case, please ignore my initial suggestion re. removing the padding from — I mixed up this instance (which is rendered in a popover) with the one below (rendered in the sidebar).
It looks like the popover's contents have an
8px
margin added directly by theDropdown
component (see the code here) (which I'm definitely not a fan of!)In this specific situation, I'm not sure if there's a clean way to avoid the style override 🤔
@mirka , any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One solution that comes to mind is how the
Card
component does it. It has a designated<CardMedia>
component that you put inside<Card>
when you want to break out of the padding. We could provide a similar subcomponent forDropdown
. ("Media" is not a very discoverable name for this, so ideally we'll give it a more literal name like<DropdownContentFullWidth>
or something.)I'm fine with the hacky style override as a temporary thing for this PR to land, and we can make a
DropdownContentFullWidth
in a separate PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the mockups in #38277 (cf. some of the implementations in Global Styles ▸ Colors), I'm wondering whether we've thought through the decision to make the tablist break out of the parent padding or not. There seems to be a lot of hierarchical contexts where it would be better not to be full-width. I wanted to check on this point because it does add a good amount of complexity and fragmentation risk if we don't have a clear style guide.
It's totally fine if some top-level tablists are full-width (e.g. Blocks/Patterns, Template/Block, Post/Block). But for things that aren't really top-level, or for components that are reused in multiple contexts such as this
ColorGradientControl
, things will be a lot simpler if we don't go full-width. Again, your call, but just a consideration from the maintenance/consistency standpoint 🙂 (cc @javierarce)