Re: Urgent Need for a Standardized Multi-Select Component

For what it's worth, I agree with Chaals

I think the current specification is absolutely sufficient for what it aims
to be. However I also agree there are three issues with the current
situation:

1. Platform-appropriate multi-select controls are no longer viable for
Windows users.
I think the situation here is a little bit strange, because I think what
the browser vendors are doing is absolutely correct: Any Windows user
should know that Shift selects lists, Ctrl selects multiple... it is the
standard across the whole OS after all.
However I think in reality at best half of all users know this. This isn't
a shortcoming of the specification, it's just a weird situation where
platform standard is no longer appropriate for average users. A list of
checkboxes might stand a chance, but again: That's not an issue with the
specification, it's something for browser vendors to figure out. More than
a hint that "how to select more than one entry should be self-explanatory
to the user" isn't something that's up to the spec.

2. Lists may need to contain non-selectable information.
This is something that I honestly feel is covered partially because options
have titles. However there is the issue of grouping or other additional
information. The only way I can see so far is including disabled options as
headers. However one could of course simply use multiple select multiple
elements for grouping, so my feeling is that this is covered sufficiently.

3. The available options may be dynamic.
I feel that this isn't sufficiently covered. Imagine for a moment that you
select one option and another one should become available when you do. Of
course you can do it by slipping in additional option elements in response
to a change event, but due to the list-based display it's going to look
really awkward.

I can see Katie's point, but I quite honestly think that redefining select
multiple is the wrong way. This element is actually defined as a list-type
element and for that it works as intended (except for #1 but again that's
not really up to the spec). Instead there should be a separate element that
does not require the UA to follow list-based selection principles, but
rather any input method that's appropriate for selecting multiple values
from a potentially long list on that platform.

This is really just an example for what I have in mind, but something like

"The browse element should display a platform-appropriate method for adding
and removing one or more items to/from a selection.
The options are derived from the inner content and must be presented as if
each sub-element were inside a block-level element containing the elements
when shown. However they may be shown only when the user signals an intent
to add an item.
Each sub-element may contain zero or more option elements.
Any option element specified at any level below the element must be
selectable either directly or through additional dialogs.
Whenever one option element is shown everything up to the parent that is a
direct descendent of the browse element must be shown along with it.
Implementers are allowed to optimize the order of options only if the
unsorted attribute is present.

The value attribute must contain a space-separated list of all currently
added values while the selectedOptions must contain a list of options
elements that the user has indicated to be part of the current selection.

If the free attribute element is present, implementers must provide a way
to add a custom value to the list of selected options where the value
indicated by the user becomes both the value and text content of an option
element that is part of the selectedOptions property of the browse element,
but not the content of the browse element. No custom value may be added
that is identical to an option element that's already present, however the
user-agent should provide a way to replace the custom value with the option
element (this may happen automatically, no user confirmation is required).
In case of conflict (for example due to changes in the DOM) the custom
value must automatically be replaced.

Setting the value attribute must select all options elements that match.
Unknown values in the value attribute must be added as custom values only
if the free attribute is present.
Implementers should, if the number of options exceeds a
platform-appropriate length, offer a method of searching the list for
text-content of the option elements.

Highlighting should appear at the topmost element that contains only a
single option element.

The text content of all selected options must be visible in the element at
all times (although it may overflow) inside the browse element, but the
available options may be displayed only when the user signals an intent to
add an additional option. An option to remove a selection should be visible
on all currently selected entries.
"

That's very crude I know, but I hope you get the idea.

Event-wise this thing would have to be pretty dumb in order to leave room
for implementers to choose an appropriate display format. Basically little
more than a change event.

The idea is that an implementer can show a list where appropriate, but is
also free to for example provide a tag box with a search dropdown where
options are shown only when the element is clicked or maybe even offered as
suggestions when the user starts typing.

so

<browse>
   <option>Foo</option>
   <option>Bar</option>
</browse>

might look like select multiple, but

<browse>
   <option>Foo</option>
   <div>
      <h2>Greeting</h2>
      <option>Bar</option>
      <option>Hello</option>
   </div>
</browse>

would be equally valid and in this case would (if it fits) present (for
example) all three options, but with a header for Bar and Hello.

And if there were too many options it might show a Tag-style add list where
if you searched for Foo it would show Foo, but if searched for Bar, it
would show the whole div containing Greeting, Bar, Hello as options...
meaning it would always have to show the "context" of each option when
offering it.

Like I said, it's a very crude draft, but I can see the value of having a
select multiple that's free to choose an appropriate display method.
However I wouldn't recommend just redefining select multiple.
As for issue #1... that's really something that would have to be discussed
with vendors. I don't see how any change to the spec could solve this
dilemma.

Any notes on how this kind of element can't possibly work are more than
welcome, but like I said the specifics are just a rough draft to paint a
picture, so no need to dwell too much on those yet. We'll get to the
details soon enough if there's interest and consensus on whether the idea
as a whole even makes sense.

Best Wishes
Hans Schmucker



On Sat, Aug 23, 2025 at 8:06 PM Chaals Nevile <chaals@fastmail.fm> wrote:

> I agree with the idea that a better widget for multi-select would be
> great. But I don't see what the specification is missing.
>
> The fact that lots of people have developed better UX suggests that people
> have a pretty good idea of how to improve the browser implementation - but
> whenever there are several different possibilities, the question arises of
> whether it is better to keep something basic and let library developers
> offer the range of extra possibilities.
>
> Seems like the issue is more one of implementation in browsers. With very
> few native browser display systems left, I suspect those who own them are
> likely to tell us "but it's open source, and you can make a Pull Request"