Repository navigation
Menu: Align group labels and separators with indented item labels. - #83993
Conversation
When a radio or checkbox column shifts item labels, headings and dividers follow that same inset so the menu reads as one column. Co-authored-by: Cursor <cursoragent@cursor.com>
jameskoster
added
[Type] Enhancement
Co-authored-by: Cursor <cursoragent@cursor.com>
🤖 PR meta 🤖🎉 PropsIf 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. Updated as activity occurs, without notifying anyone named here. Add the 📦 Bundle sizeSize Change: +328 B (0%) Total Size: 8.25 MB 📦 View Changed
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
|
|
Seems a good small step. One thing I'd love is to make the icons smaller, and to make the reserved space/indentation on the left smaller too. Not in this branch, but is that feasible now we have stroke icons? |
|
Would you like us to change the group label alignment for the other item popup components as well? We currently do this: 
|
|
If you're asking me, re: the items on the left, I want to note that it's a soft feeling. I don't think what we have is very poor, I think it's very close and able to benefit from just small iterative PRs like this one. I'm a fan of your work, all of you. So to answer: I think it's a matter of freeing up about 12 to 18px of space on the indented side of menus. About making menu items about as small as we can make them. The MacOS menu bar is actually a good model to follow: 
The icon is about 18x18, there's about 4px of outer padding, 6px of inner padding, very little gap. I defer to you all on what's possible. |
My expectation would be that yes, we should apply the same feedback where applicable to other components
I agree and I think we need more changes:
More controversial choices:
|
Menus may be a special case, but for the selection popups, I tried to establish in the documented patterns that groups with labels don't need separators: 
|
|
Here my thoughts:
But how is it recognizable before interacting which options are single-select or multi-select? To me, this is the main problem, and the check or dot visual language is already used in checkboxes and radio buttons, so there is nothing new to learn.
I was thinking about this too. I don’t dislike the all caps version, but as part of the practices, we need to avoid using it because menus are contextual to the element that triggered them. The ellipsis menu in the Editor is trickier because it gathers different types of actions, but in most cases, the options displayed are already contextualized. IE, the ellipsis menu of a block in the ListView sidebar. In addition to the above, I was thinking about using icons to highlight certain items. In the Editor’s options menu, showing an icon for the “Style” item makes sense, as it’s a section some users might not be aware of, but “Export” seems unnecessary, as the action is widely understood and the help text clearly explains what it does. 
The rule that makes sense there is to show an icon on all group items if one item shows it. |
|
A small update: this is how the options menu looks now. We removed the export icon. The items in the Panels submenu are usually from 3rd parties, where we have less control. Icons could help there to differentiate sources (in most cases). Screenshot
|
Good point, we should understand if we need separators in menus. My instinct says "yes", but curious to hear what others think, too
I know, and I was strongly in favour of radio dots. But we keep getting pushback from design and product stakeholders, and users don't always seem to understand what the radio dot means anyway. So that's why I'm proposing we use checkmark: it makes the new menu closer to the legacy (ie. less overwhelming), it trades off a better visual affordance of the behaviour, for fewer "signals" to scan. I now believe that we should use checkmarks, at least initially, and separately investigate if / how to put radios back in a way that is aestatically more pleasing and more clear to end users . MacOS doesn't use radios, for example. Base UI examples don't either 
Yes, but this is tricky to enforce at the component level: we can mention it more prominently in the docs, and potentially even add dev-time warnings for it, but ultimately consumers will have to add those icons themselves. |
I think this doc is how most libraries or guidelines communicate similar requirements. "Yes, you can, but we recommend against it since it will look bad." Warnings add extra complexity and could also be ignored by consumers. |
|
I opened #84015 stacked on top of this PR to work on spacing around checkbox/radio and prefix icon sizing. I will also open a separate PR soon to test the "checkmark for radio items" change. |
ciampo
left a comment
ciampo
left a comment
There was a problem hiding this comment.
I think this is an improvement over what we have on trunk 🚀
Implementation is clean and reuses current grid tracks
|
My 2c:
|
Implementation suggestionsI acknowledge the lack of control over what others can do, my suggestion points to the default system and the patterns we can document for designing menus. In that vein, the design itself suggests a preferred outcome, as showing just one icon adds empty space for the whole group and breaks the layout. Removing the icon in Export fixes that unnecessary indentation. So the "Yes, you can, but we recommend against it since it will look bad” sounds good to me. Checkmark or notI trust you all instincts in using checkmark as a single language, I’m mainly concern of cases where both single- and multi-selection are side by side, but that can also be addressed by putting these elements inside submenus. In that vein, given the extender’s flexibility and adaptability, can it automatically generate a menu instead of creating a set menu when only one item exists? A submenu with a single option is not a good decision. I haven’t looked at #82974 where this work happened. 
Design ideaHere is an idea that involves all points mentioned by @jameskoster here 
And here adapted to the current Editor's options menu in 7.1 
Design |
|
I'm going to merge this, let's continue to discuss the other details elsewhere. |
…ordPress#83993) Co-authored-by: jameskoster <jameskoster@git.wordpress.org> Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: mirka <0mirka00@git.wordpress.org> Co-authored-by: fcoveram <fcoveram@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
That could be tricky, but not impossible. We'd need to check One alternative is to treat those items as regular menu items instead of radio, ie. items that, when clicked, perform an action (open/pick a panel). This is what MacOS does when choosing a window alignmen option: 
|
Need to double-check the internals, but I think that should be possible. I'll have a look on Monday. |
|
Trying an approach in #84033, which also adds an Inspector panel entry |
6 participants
Follow-up to #81564.
What?
Align
Menugroup labels and separators with item labels when a radio or checkbox column indents those labels.Why?
A radio or checkbox reserves a column for the whole menu, so every item label shifts right. Group headings and dividers kept the original inset, which left them sitting to the left of the text and made the menu harder to scan.
How?
Group labels and separators now start after the shared selection track and end with the item content column. Prefix icons stay in their own per-group column, so an icon in one group does not shift headings and dividers in the rest of the menu.
--wp-ui-menu-group-head-padding-inlinestill nudges both edges; its default adds no extra offset.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Use of AI Tools
Cursor (Grok 4.7) assisted with the implementation. The change was reviewed before commit.