Should <select multiple> be part of <selectmenu>, or is it a separate control?

[dandclark]

A number of previous issues have danced around the question of <select multiple> behavior as it relates to the <selectmenu> proposal.

https://github.com/openui/open-ui/issues/113 https://github.com/openui/open-ui/issues/104 https://github.com/openui/open-ui/issues/153 https://github.com/openui/open-ui/issues/142 https://github.com/openui/open-ui/issues/152 https://github.com/openui/open-ui/issues/380

I'd like to try to conclusively resolve whether multi-select support is something that should be built-in to <selectmenu>, or whether multi-select behavior is sufficiently different that multi-select should be considered altogether separate control.

My preference is to not include multi-select support in <selectmenu>. I'd like to keep the control on the simpler side, and there are a number of differences in how the two modes would behave that would complicate things. E.g., up/down arrow on an open listbox popup would update the value and fire input events for a single-select, but probably not for a multi-select.

Supporting both would make it challenging to make an API surface that makes sense for both modes -- e.g. selectmenu.selectedOption vs selectmenu.selectedOptions.

Thoughts?

[chrisdholt]

Supporting both would make it challenging to make an API surface that makes sense for both modes -- e.g. selectmenu.supportedOption vs selectmenu.supportedOptions.

I think this is an unfortunate reality; breaking this apart would require another select to address multiple and likely push us into uncomfortable naming territory. My $0.02 is that API challenges aside, a single control here is more familiar and expected than two. That certainly doesn't mean that it must be a single control, but I'm not sure that complexity should be a primary deciding factor.

[gregwhitworth]

My gut instinct is to agree with @chrisdholt but after looking at Bootstrap, Lightning, and Material some don't offer multiple or they follow the paradigm of native where the listbox is dropped into the page. That said I know I've engaged with dropdowns that allow multiple - Github's label picker is a good example of this.

Given this, I'd prefer to add the content attribute and embrace the additional complexity and since the parts will be surfaced the component libs that want to have it inset they can achieve this via CSS style adjustments.

I'd note that we can do this iteratively since we know the behaviors will be different and complete the current iteration and add in multiple next.

[css-meeting-bot]

The Open UI Community Group just discussed Should <select multiple> be part of <selectmenu>, or is it a separate control?, and agreed to the following:

• RESOLVED: resolution: we should work on specifying a <listbox> element that supports single and multi-select capability.

The full IRC log of that discussion

<gregwhitworth> Topic: Should <select multiple> be part of <selectmenu>, or is it a separate control?
<gregwhitworth> github: https://github.com/openui/open-ui/issues/447
<gregwhitworth> dandclark: our current selectmenu currently punts on multi select. Should it be a part of selectmenu or a different element
<bkardell_> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> dandclark: this comes down to what devs expect but one concern I have is around the API surface
<masonf> q+
<gregwhitworth> dandclark: there is a selectedOption that we'll want but with multi select we'll want an array. You see this today where the APIs diverge based on the potential forms the select can take
<gregwhitworth> dandclark: I don't want to duplicate that however
<gregwhitworth> dandclark: I'm looking to this group with more experience
<gregwhitworth> dandclark: chrisdholt says that devs will expect them to be the same and gregwhitworth says there are some that don't do that
<gregwhitworth> ack bkardell_
<hdv> +1 to chrisdholt point!
<miriam> q+
<scotto_> q+
<gregwhitworth> bkardell_: +1 to a whole bunch of things based on the challenges and reasons not to
<chrisdholt> If the approach is a separate `listbox` element for multi-select, I'd be curious why we bake the default single select listbox...listbox supports both single and multi, but the select listbox would only support one. Seems odd.
<gregwhitworth> bkardell_: to the point to what devs expect but we have this problem what we think the actual native ones are design mistakes and I would think this is one of those
<gregwhitworth> bkardell_: devs will naturally expect something similar to what they already know
<gregwhitworth> bkardell_: I don't think that's a good reason to promote this
<gregwhitworth> q+
<gregwhitworth> bkardell_: I would be in favor of two seperate elements
<chrisdholt> q+
<gregwhitworth> masonf: bkardell_ said what I was going to say
<melanierichards> q+
<gregwhitworth> masonf: the only issue there is if we create widespread confusion
<gregwhitworth> masonf: I think we can get around that if it's easier to understand
<gregwhitworth> masonf: we already have the anatomy of the select that has a listbox
<chrisdholt> That is what I would expect if we do two elements...
<chrisdholt> q-
<gregwhitworth> ack masonf
<gregwhitworth> miriam: I was going to say that as an author I would be surprised. but if 2 elements landed I would be perfectly fine with that
<gregwhitworth> miriam: it wouldn't matter a whole lot
<gregwhitworth> ack miriam
<gregwhitworth> ack scotto_
<davidluhr> +1 for two elements. We can offer zero-config, tailor made elements with dedicated semantics and functionality.
<chrisdholt> q+
<gregwhitworth> scotto_: I like the idea of them being two different elements is to have a select element that has a listbox popup that allows for multiselect
<gregwhitworth> scotto_: the 2 options are either a menu with popup or an inset for multiselect
<masonf> miriam: what if there was only a concrete plan to land the second (multi-select) part?
<davidluhr> q+
<gregwhitworth> scotto_: does this mean that a selectmenu with a listbox would be off the table?
<gregwhitworth> scotto_: would they just need to do a listbox
<miriam> masonf: I'd be eager for it to land :p
<gregwhitworth> scotto_: I don't have opinions either way
<gregwhitworth> dandclark: I don't think any of that is off of the table, but we do need to make a call of the behaviors in their default state
<gregwhitworth> dandclark: even the native one as it's written now can be done
<davidluhr> gregwhitworth: To add to what Scott said, this is heavily related to <popup> and attributes discussion.
<davidluhr> gregwhitworth: The anatomy is overall the same, which is why I was leaning to having popup as a property in CSS.
<davidluhr> gregwhitworth: I personally echo Nicole Sullivan in rather having a billion attributes, instead having dedicated tools that are clear in their purpose.
<davidluhr> gregwhitworth: The listbox on a <selectmenu> is going to be rendered at the top layer. With <selectmenu multiple>, it would just be `display: block;`. Are the majority of multi-selects inset because of current implementations, or would people prefer a listbox presentation?
<davidluhr> gregwhitworth: In my opinion, it comes down to them having different behaviors, so I'm in support of them being two separate elements.
<gregwhitworth> ack gregwhitworth
<gregwhitworth> melanierichards: basically wanted to support exploring multiple elements for this
<gregwhitworth> melanierichards: a different part structure may be helpful for the UX issues
<gregwhitworth> melanierichards: I also wanted to advocate to slow down and take our time for the multiple select usecase
<gregwhitworth> melanierichards: the question on a recent podcast was select multiple and I know folks bypass this and we should document why and help inform the design path forward
<gregwhitworth> melanierichards: at first blush I'd support 2 seperate elements
<gregwhitworth> ack melanierichards
<gregwhitworth> chrisdholt: I could support 2 seperate elements
<gregwhitworth> chrisdholt: multiple selects the listbox of select and it surfaces through the select. I would personally find that weird, is part of the reason that we're seeing that folks aren't building this is because of the complexity
<gregwhitworth> chrisdholt: we're building this on listbox and that inherits into select and happy to share our findings
<masonf> q?
<gregwhitworth> ack melanierichards
<gregwhitworth> ack chrisdholt
<gregwhitworth> davidluhr: I support what a lot of folks have said
<gregwhitworth> davidluhr: the idea that nicole sullivan had of purpose built tools
<masonf> q+
<gregwhitworth> davidluhr: the functionality follows that
<gregwhitworth> ack davidluhr
<gregwhitworth> davidluhr: I agree with gregwhitworth that we seperate the visual from the behavior and having a multi-select that can be displayed as a listbox or inline that means it must always be that
<gregwhitworth> davidluhr: this echos the popup discussion
<gregwhitworth> ack davidluhr
<gregwhitworth> masonf: something chrisdholt said changed my mind a bit
<gregwhitworth> masonf: that listbox element should support single or both but I'm still technically supportive of both
<melanierichards> +1 to landing simultaneously
<chrisdholt> +1 on both at the same time - we need to provide a unified solution, regardless of two elements or not...
<masonf> q+
<chrisdholt> +1 to where Greg is going :)
<davidluhr> gregwhitworth: That is more and more why I'm leaning toward it being a CSS primitive to allow for the listbox to be placed on the top layer.
<davidluhr> gregwhitworth: We should have a listbox element that can be inline or a popup.
<davidluhr> gregwhitworth: The select can leverage the listbox element and we provide the necessary primitives to display it how we would want.
<gregwhitworth> ack masonf
<davidluhr> q+
<gregwhitworth> masonf: I've been brainstorming a lot and popup would look a lot more like a primitive and so it works with what you just said
<gregwhitworth> davidluhr: I agree with what you said gregwhitworth
<gregwhitworth> davidluhr: I did some research on my own and what a listbox for a popup element can look like it being an affordance of attribute or CSS property. Looking at spicy-sections and having it queryable is great
<chrisdholt> +1
<dandclark> Proposed resolution: <selectmenu> only supports single-select. When we add multi-select we will do so as a separate element.
<masonf> Proposed resolution: we should work on specifying a <listbox> element that supports single and multi-select capability.
<gregwhitworth> RESOLVED: resolution: we should work on specifying a <listbox> element that supports single and multi-select capability.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

Quick note that we resolved (https://github.com/openui/open-ui/issues/531#issuecomment-1145170806) not to handle the multi-select case in "v1".

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

Now that we are reusing the select element, my plan is to make the multi-select thing part of <select multiple> as well.