-
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
Components: Simplify MenuGroup component styles #65561
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. |
@@ -5,6 +5,10 @@ | |||
.components-dropdown__content { | |||
.components-popover__content { | |||
padding: $grid-unit-10; | |||
|
|||
&:has(.components-menu-group) { | |||
padding: 0; |
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.
This is the main change, basically if a dropdown contains "menu groups", it shouldn't have padding. And all the magic CSS we had in place was just to account for that double padding.
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.
What if there is a mix of menu groups and simple items?
eg.
DropdownMenu
- Menu Item
- Menu Group
- Menu Item
- Menu Item
- Menu Item
In this case, wouldn't the first menu item be misaligned?
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.
The previous style were targeting specifically menu groups. In other words, if this exists somewhere, it's already broken. So I'm guessing it was "doing it wrong" anyway.
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.
For instance The following existing style wouldn't have worked in this case
&:first-child {
margin-top: -$grid-unit-10;
}
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 tweaked slightly the Storybook examples of Dropdown
and DropdownMenu
, adding a standalone <MenuItem />
next as a sibling to <MenuGroup />
s
Click to expand diff
diff --git a/packages/components/src/dropdown-menu/stories/index.story.tsx b/packages/components/src/dropdown-menu/stories/index.story.tsx
index b6bc11ddec..dd4907bd0b 100644
--- a/packages/components/src/dropdown-menu/stories/index.story.tsx
+++ b/packages/components/src/dropdown-menu/stories/index.story.tsx
@@ -96,6 +96,9 @@ export const WithChildren: StoryObj< typeof DropdownMenu > = {
icon: more,
children: ( { onClose } ) => (
<>
+ <MenuItem icon={ arrowUp } onClick={ onClose }>
+ Standalone Item
+ </MenuItem>
<MenuGroup>
<MenuItem icon={ arrowUp } onClick={ onClose }>
Move Up
diff --git a/packages/components/src/dropdown/stories/index.story.tsx b/packages/components/src/dropdown/stories/index.story.tsx
index c6fe5014ff..0f07664787 100644
--- a/packages/components/src/dropdown/stories/index.story.tsx
+++ b/packages/components/src/dropdown/stories/index.story.tsx
@@ -99,6 +99,7 @@ export const WithMenuItems: StoryObj< typeof Dropdown > = {
...Default.args,
renderContent: () => (
<>
+ <MenuItem>Standalone Item</MenuItem>
<MenuGroup label="Group 1">
<MenuItem>Item 1</MenuItem>
<MenuItem>Item 2</MenuItem>
This scenario worked fine on trunk
, but is broken in this PR:
Before (trunk) | After (this 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.
Thanks for testing further. Personally, I still think that's "doing it wrong" but I pushed some CSS to fix it.
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.
Do you mean mixing standalone menu items with menu groups?
It may seem unusual (and we may discourage), but semantically it's valid and it's definitely an outcome of how consumers of the library can composite those components. Also, we may not have full control about this either in Gutenberg, depending on where the slotfills are.
IMO it's definitely a good thing to make sure this scenario looks and works as expected in any case.
2db2e1a
to
15fb8dd
Compare
Size Change: +66 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
Flaky tests detected in 15fb8dd. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10991046477
|
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.
Left a couple of comments, but also realised that in theory there is already a check in place:
gutenberg/packages/components/src/menu-group/index.tsx
Lines 36 to 38 in c566725
if ( ! Children.count( children ) ) { | |
return null; | |
} |
Is that check not working as expected? If that check worked as expected, I guess there wouldn't be the need for any other changes?
Yes, the check doesn't work because of Slot/Fill. The slot is always rendered even if there's no fill, so basically children is always not empty. |
Got it. I guess the correct way would be for A potentially better compromise would be to set the Diff to apply to trunkdiff --git a/packages/components/src/menu-group/style.scss b/packages/components/src/menu-group/style.scss
index d9412c5049..c6119ec0ff 100644
--- a/packages/components/src/menu-group/style.scss
+++ b/packages/components/src/menu-group/style.scss
@@ -1,3 +1,7 @@
+.components-menu-group:has([role="group"]:empty) {
+ display: none;
+}
+
.components-menu-group + .components-menu-group {
margin-top: $grid-unit-10;
padding-top: $grid-unit-10;
|
This is what the PR is solving (see related comment in the other PR). For me the fix is simple enough that it's worth doing. Also this style is better and simpler to understand than the negative margins we have in trunk. |
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.
This is what the PR is solving (see related comment in the other PR). For me the fix is simple enough that it's worth doing. Also this style is better and simpler to understand than the negative margins we have in trunk.
Yup! The only difference is that I was also ok with leaving the trailing extra margin, if that simplified the code changes / allowed us to merge the fix quicker. But I see that you pushed an updated version that doesn't break previous usages AND fixes the empty group case, so that's great!
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.
9607ba8
to
599f7e1
Compare
599f7e1
to
5859fb4
Compare
This is meant to address this comment #65485 (comment)
What?
Basically, sometimes we have MenuGroup that are empty but because of how these components are styled, you end up with some weird spaces or separators when it happens.
The main issue is that we used to rely on
+
CSS selectors to style multiples groups and consecutive groups. But the good news is I think we can simplify these styles. Initially we used this kind of styles because we didn't have the possibility to use:has
selector (it was not supported).Testing Instructions
Check the different dropdown menus: (block settings, more menu...) and ensure that spacing and separators all look correct.