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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +423 B (+0.02%)

Total Size: 2.47 MB

_{compressed-size-action}

So I guess this is the wanted alternative for #72844, that I had a PR ready?

@ntsekouras we could have both. Your PR is a bit better from an a11y perspective as it makes this feature available to keyboard users. Although having said that it's already available in the appearance options panel, so I can go either way on this :)

@youknowriad Couldn't we use Menu here? It handles/offers everything we want in a consistent way.

The styling as-is seems a bit broken, double border, strokes between items:

@jameskoster This uses the same component as the one used in the view config dropdown, I think ideally we'd have a lower level abstraction than Menu that can be used for both within Menu (DropdownMenu) and inline.

Maybe @aduth can talk about how we can do this.

Yes we've spoken a few times about Menus that appear 'inline' in other UIs, but didn't have a valid use case yet so it hasn't been prioritised. There's also potential overlap with navigation menus to consider as well.

But in this case doesn't it seem like Menu would be a better fit compared to the ad hoc view config dropdown implementation? It's literally a menu, with no other adjacent affordance :D If not, should we update the styling to match?

But in this case doesn't it seem like Menu would be a better fit compared to the ad hoc view config dropdown implementation?

No, it's not possible the Menu renders contextually to a button not to the mouse position. We might need a dedicated ContextualMenu component or something like this.

should we update the styling to match?

I would love thoughts from @aduth on how to go about this, I think the way we make styles match is by using the "inline menu" component.

I think we'll want to have a dedicated ContextMenu component (like BaseUI) or at least a documented pattern (like Ariakit) that wraps Menu and handles all of the positioning and interaction details (i.e. reusing Menu with some extra behaviors).

With how Menu is currently implemented, it's not currently possible to use it like how we're using Popover here to arbitrarily position the menu.

A realistic short-term solution could be one of:

• Allowing Menu to be positioned, exposing some way of assigning an anchor element or position similar to what Popover does. Technically this exists with how Menu.Popover passes through to Ariakit.Menu and Ariakit.Menu supporting a getAnchorRect, but the current TypeScript types don't expose this.
• Allowing Menu parts to be used inside Popover, so we could at least have consistent visual appearance. This is not possible currently because menu items require the menu's context

Another option that could be done today without changes to Menu would be to interact with the menu's internal store to assign an anchor element. I don't love this though, since ideally I don't think we'd be exposing the internal, library-specific context store for external usage. I think we should change this, because otherwise it binds us to a specific implementation.

As far as the reusing parts between the config menu and the context menu, I'm not sure these are the same kind of thing, since the context menu items feel more like menuitemcheckbox (WAI ARIA example), with the config more like a (multi-)select or group of checkboxes. We might be able to implement a component which has some default semantics but allows for control to override with a context-relevant role, but it could also be that these are separate components, and what's shared are common styles / design tokens.

As a user, I feel like this is the same thing. I'm selecting which fields are available. If the UI is triggered using right click or a trigger (the view config dropdown trigger) feels really secondary.

That's a fair point, but don't you think context and design can play a role? It seems clear that the right-click affordance should be a Menu because it only handles one aspect and feels like a quick action. But I think there might be a case to use different semantics in the config UI.

If we used checkboxes/toggles the property visibility section would be more congruent with the rest of the UI, presenting as a single form rather than a form + a menu. The layout would be more compact, sidestepping the boxes-in-boxes issue the current design suffers from a bit. Finally it'd lessen the urgency to implement the 'inline menu' functionality.

Menu	Checkboxes

Implementing pointer anchoring for the Menu would still be necessary, but it appears achievable, and given its broader application it would be a valuable enhancement beyond this particular scenario.

In discussing with Andrew I came to realize something:

• A checkbox is something you persist as a boolean (this is visible true or not).
• A list block is you select an array of items out of a bigger array.

Now, I'm strongly convinced that this is not a checkbox. We actually store this as view.fields: string[]. This is really a multi-select semantically.

If you're strongly convinced then so am I :)

It would still be nice to fix the styling in the context menu though 😄

Yeah, I think we should fix the styling ideally in a reusable UI component that we can use between both context. What would be the desired style here?

Just to be sure we're talking about the same thing, are you saying it's a listbox pattern because it behaves like a multi-select list, rather than a 'random' list of checkboxes?

If so we already have a design for that here: #65801 which can serve as a starting point. I should note that the 'checkboxes' in that concept are not inputs, just elements styled to look like checkboxes to indicate the behavior. I'm happy to use simple checkmarks (like we did here) if that's the preferred approach though. Is this a component you see living in the new UI package? If so the design will need a slight refactor to utilise the new color tokens.

I was thinking about the default browser multi-select (without aria), but it may correspond to the listbox pattern, I don't know to be honest.

I would love for this component to live in the new UI package if possible yes :)

You mean <select multiple>? I suppose that would be simpler, but I think it's a bit tricky to style, and multi-selection requires keyboard interaction (e.g. shift-click or cmd-click) which would probably be a bit clunky/unintuitive in this context. Let's see what @aduth thinks.

@jameskoster I was not saying that we should be using it as is and style it, instead I was saying that it's the same semantics for me.

width: min-content in the surrounding popover is causing these menus look a bit weird.

With fit-content it looks good:

I experimented a bit with the listbox idea to determine feasibility and effort.

Feasibility

One design implication I noticed for using the listbox pattern in isolation (i.e. "inline") is that we'll need a focus ring on the entire list to indicate that it's a composite widget with a single tab stop. Is that ok? This detail hasn't been captured in existing mockups.

Effort

We'll likely need to build this as a custom component using Ariakit Composite.

I was hoping we could simply render the listbox in Base UI Select outside of its popup, but it currently doesn't support this. We can request support, but I'm not sure if they'll find it worthwhile. Base UI Combobox does currently support rendering the listbox outside of its popup, but unfortunately the keyboard interactions of a combobox listbox is slightly different from a normal listbox (in a combobox, items cannot be selected by Space).

Alternative: CheckboxGroup

While I'm fine with investing in a Listbox component if we agree it's worth the effort, there's still a possibility we do not need one. Our new UI package will have a CheckboxGroup component, which will allow consumers to handle the checkbox values as a single array, rather than a bunch of boolean values. So devex-wise, there's no inconvenience. Screen reader users may incur a slight inconvenience depending on the number of items in the list (harder to discern the total number of items, your current index in the item list, etc), but given that we probably wouldn't be using this pattern for more than a handful of items, I wouldn't say it's a blocker.

On the context menu side, I agree with @aduth that we can have a dedicated ContextMenu component. We'll also be updating the Menu styles soon to use the new checkbox-style indicators, so visual consistency will not be a problem.

I think @mtias have some strong feelings here about the design being very light (no actual checkbox, but an icon) and I'm not sure about the whole focus ring, that feels very weird to me to be honest.

@simison I swear I though I fixed this using flex-string: 0 or something like that. Maybe it didn't solve all use-case. Please if you have time for a quick PR, go for it.

Huh, now I refreshed the page and it works again! Maybe some styles were still loading from the old version. I'll let you know if I see it again!

@mirka I know we've discussed a lot when to use checkbox-appearance vs. plain icon but I can't remember all the details 😅 Do you think a plain icon could work in listbox?

Also, could it be appropriate for the focus ring appear on focus-visible to reduce the visual weight for mouse users?

I still think a checkboxgroup would be a better fit for the appearance config popover 🙊

@mirka I know we've discussed a lot when to use checkbox-appearance vs. plain icon but I can't remember all the details 😅 Do you think a plain icon could work in listbox?

It all started from Menu, when there can be single and multiple select item groups, sometimes in the same menu. We wanted clear cues to differentiate between the two. Then, it followed that we should use the same cues for other single/multiple select UIs, like Select and Combobox.

It's tricky. Not all contexts require a clear differentiation between single/multiple, but in the few cases where it is needed, we can't differentiate them without a consistent cue that's already been established across the system 😅

Given the difficulties we're starting to see with the checkbox-style indicators, I can think of two paths forward:

1. Discard the idea that we need to differentiate between single/multiple selects. Some design systems take this stance, for example Apple.
2. See if we can decrease the prominence of the multiple-select indicator. Would it help if we removed the accent color and made it neutral? No background fill when selected?

I still think a checkboxgroup would be a better fit for the appearance config popover 🙊

Same! Would you be fine with that @youknowriad?

Same! Would you be fine with that @youknowriad?

what would do that look like? I think @mtias kind of feels strongly about this menu looking very similar to finder's columns menu. I'm not the one to convince here :)

Menu still seems to be using check icons rather than checkboxes, so I guess we aren't fully committed? I'm hesitant to discard but this does remind me of the recent Combobox issue we faced. Maybe it's not so important to visually distinguish if we ensure appropriate labeling? In this case a group label might make the multi-select aspect clear; "Toggle property visibility"?

this menu looking very similar to finder's columns menu. I'm not the one to convince here :)

Wasn't that mostly about the context menu? I agree that should be minimal, basically a Menu with checkboxes instance. The popover would look like the mockup in this comment.

Wasn't that mostly about the context menu?

I think it was for both (AFAIK)

Menu still seems to be using check icons rather than checkboxes, so I guess we aren't fully committed?

It's not that we weren't fully committed, we just haven't made all the changes in code yet 😄

So, given that this is a decision we can reverse later without major disruption, how about we revert all our "checkbox-style indicator" plans for now, and see how that goes? Plain checkmark indicators for both single and multiple selection — in all menus, selects, and comboboxes.