Open dandclark opened 2 years ago
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.
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.
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.
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.
Quick note that we resolved (https://github.com/openui/open-ui/issues/531#issuecomment-1145170806) not to handle the multi-select case in "v1".
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.
Now that we are reusing the select element, my plan is to make the multi-select thing part of <select multiple>
as well.
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.
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 thevalue
and fireinput
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
vsselectmenu.selectedOptions
.Thoughts?