[Select] What to do with selectedcontent when multiple select is set with size 1

[brechtDR]

I think this might be an interesting topic to discuss in the (near?) future.

I was wondering how a <selectedcontent> should behave when multiple select is set with a size="1"

<select multiple size="1">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option>option</option>
  <option>option 2</option>
  <option>option 3</option>
</select>

I like the idea of it outputting every selected option right after each other instead of 2 selected, 3 selected when more than 1 item is selected.

I would not foresee any comma separation for this, as this can probably easily be customized with pseudo-elements.

<select multiple size="1">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option><div class="wrapper">option</div></option>
  <option><div class="wrapper">option2</div></option>
  <option><div class="wrapper">option3</div></option>
</select>

selectedcontent .wrapper::after {
  content: ',';
}

I thought this was a good idea, but other suggestions are more than welcome. It should at least be looked into.

[mkrause]

Fully agreed with this, having the basic "[N] selected" string would block a lot of customization, having the actual item content seems like a much better approach to me and would better match the behavior of the existing single-select <selectedcontent>.

[lukewarlow]

I would not foresee any comma separation for this, as this can probably easily be customized with pseudo-elements.

I think the issue with that is the default experience is poor.

<select multiple size="1" style="appearance: base-select;">
  <option selected>hello</option>
  <option selected>world</option>
</select>

Even if we space separate them that's confusing.

Now perhaps we could make it so it's "n selected" in the default button and then different content with <button><selectedcontent> inside, but that feels weird too (also means you can't implement it by just putting that in your internal slot).

Given you can give the button any content you want with JS, is that an okay trade off?

Working out that default out of the box rendering will be the hardest part I think.

[mkrause]

Thanks @lukewarlow. Maybe taking a step back and asking a preliminary question: what would be a good default experience here in the first place?

The current behavior (at least in Chrome 144 with its support for a multiple-selection <select> in combobox mode):

No options selected displays "0 selected":

One option selected displays the selected option label:

Multiple options selected displays "n selected":

Is this a good user experience? I feel like it's less than ideal:

• There's an inconsistency between one item selected vs. zero or multiple.
• In the case of multiple selected, I cannot actually tell what those options are without opening the picker.
• The formatting depends on the user's language.

I did some quick testing with a screen reader and this experience doesn't seem great either in the case of multiple selected options.

Is this something we think could still change? Or is this considered fixed/expected behavior especially since it's already shipped in a major browser?

[lukewarlow]

It's definitely not set in stone, especially because it's appearance auto not appearance base. So it's ultimately up to the UA what they do anyway.

One thing to be aware of though is it is consistent with how it's always worked on android (which has had a combobox multi select forever).

I believe the same is true for iOS Safari which similarly has always had combobox for multi select.

That's not to say we can't change it but I think it's something we'd need to work out a solid reason for changing. For screen readers is it a chrome bug or does it behave that way on Android and iOS too.

[mkrause]

A few more thoughts on this:

Having (the DOM state of) <selectedcontent> be 1:1 with what the browser displays by default seems to defeat the point of this element in the case of customizable multi-select, given that the user is opting to customize the display but now does not have the information available necessary to customize this beyond some browser default (and language-dependent) string.

I'm wondering whether the (default) presentation of <selectedcontent> needs to match the DOM contents. I could imagine some kind of CSS opt out to display the contents of the DOM instead. This would have accessibility implications also though, I'm not sure whether this is a good idea. Also: the appearance: base essentially is the opt-in to take control over the styling already, so adding another layer of opt in seems unnecessary (although: see the situation with the separate select ::picker opt-in).

Lastly, I wonder if there is a way to just make the default styling work better. For example: would it make sense to not just concatenate the selected <option> contents, but instead wrap in each in some wrapper element out of the box. This would open up doors for UA styling to provide a better default (if needed even some kind of magic content: -ua-default-selected-content override to get the "N selected" string back).

Maybe:

<select multiple size="1">
  <button>
    <selectedcontent> <!-- DOM state: -->
      <option>option 1</option>
      <option>option 3</option>
    </selectedcontent>
  </button>
  <option selected>option 1</option>
  <option>option2</option>
  <option selected>option3</option>
</select>

Using <option> here again is probably a bad idea (will existing parsers read these as an <option> of the <select>?), and this is now inconsistent with single-select. But just throwing it out there

EDIT: Yeah, using <option> for this wrapper won't work. Firefox (v147) for instance will parse the <option> from inside the <selectedcontent>.

[brechtDR]

Even if we space separate them that's confusing.

@lukewarlow couldn't we CSS separate them with inline-block and a margin in UA styles?

[css-meeting-bot]

The Open UI Community Group just discussed [Select] What to do with selectedcontent when multiple select is set with size 1, and agreed to the following:

• RESOLVED: <selectedcontent wrap={yes|no}> where the default is yes for multi-select, and no for single-select. Wrapper is a div or span.

The full IRC log of that discussion

<masonf> scribenick: masonf
<masonf> brecht_dr: on multi-select, we have size attribute too. With selectedcontent, how does this work with size=1 combined with multiple?
<jarhar> q+
<masonf> ...would be handy to display every selected options content inside it
<masonf> if you put size=1 on appearance:auto, you see "2 selected", etc.
<masonf> ...ideally show the options themselves.
<masonf> ...don't combine with a "," or anything - too limiting on styling.
<masonf> ...have user agent styles with margins between selectedcontent>option for example
<masonf> ...thoughts?
<jarhar> q?
<masonf> jarhar: thanks for raising this issue. I think that (clone all the options into selectedcontent) would be cool.
<masonf> ...allows freedom to style it how you want. Can rebuild Firefox's mobile behavior, etc.
<masonf> ...by default, we do need to make it look "ok" and not just a bunch of text. Not too concerned about that, developers will handle it.
<keithamus> q+
<masonf> ack jarhar
<brecht_dr> q+
<masonf> keithamus: another way to do this is to allow the developer to add more than one <selectedcontent> element, one for one.
<masonf> q+ maikel
<masonf> ack keith
<masonf> ...questions about what to do if the number doesn't work.
<masonf> jarhar: only first selectedcontent - we're changing that now. We'll clone into all of them.
<jarhar> q?
<masonf> brecht_dr: if we have all the options inside selectedcontent, there's no wrapper, right? Could we wrap it somehow?
<masonf> ...if you want to do the first 3 for example, easy with CSS.
<masonf> ...you can add your own wrapper element.
<jarhar> q+
<masonf> ...I'm wondering if we could do that somehow with some magic.
<masonf> ack brecht
<jarhar> i dont think we should try to wrap them in anything by default, it should be up to authors to do this
<masonf> maikel: I posted about this. The discussion is basically solved if each option is in a wrapper. Allows UA stylesheet rules that look good by default.
<masonf> ...inconsistent with single select. No wrapper there.
<masonf> q+
<masonf> ack maikel
<masonf> maikel: would like a wrapper.
<masonf> jarhar: let's not add a new element, it's up to the author to do that. Sometimes you don't want that, you might just have icons or something.
<brecht_dr> q+
<keithamus> scribe+
<keithamus> masonf: Same as jarhar. I think we should keep consistency with single select. Magic wrappers are a nono. Developers are likely going to throw it away and do their own thing. So adding magic they throw away seems a waste.
<keithamus> masonf: You cant do certain things with wrappers, unless you use display:contents and such
<masonf> q?
<keithamus> masonf: One thing: I want to make sure we can add simple rules to make it somewhat readable in the case that the developer does no work but otherwise as minimal as possible.
<keithamus> ack jarhar
<keithamus> ack masonf
<masonf> brecht_dr: I tend to agree that if you're using selectedcontent, you're probably planning to do something custom.
<jarhar> q+
<masonf> ...maybe instead of wrapping items, add a separator pseudo element?
<masonf> {But the option content could just be Text.}
<masonf> ...ack brecht
<masonf> brecht_dr: personally, I don't care much, because I'll style it myself. Shouldn't it look ok by default though? As is, it's words stuck together.
<masonf> ...maybe a separator pseudo element.
<masonf> ack jarhar
<masonf> jarhar: maybe something between them. In the case that options only have text, you get adjacent text nodes, no way to put pseudo elements.
<masonf> ...maybe wrapping would be better.
<masonf> brecht_dr: maybe hide the pseudos.
<masonf> jarhar: for text nodes, there's no place to put a pseudo element.
<masonf> ...adding <hr> magic separators makes more hassles for developers to remove them.
<masonf> ...still in favor of no magic.
<keithamus> q?
<keithamus> q+
<masonf> ack brecht_dr
<masonf> brecht_dr: I agree that I'm not going to want extra magic - first thing I'd do is hide it.
<frehner> q?
<masonf> ...if we don't have basic UA styles to make it readable, it'll be weird looking.
<frehner> q+
<masonf> ...default styling should be readable at least. That's my only concern.
<masonf> ...I don't care myself, just concerned that browser vendors will care.
<masonf> keithamus: can we talk more about cloning each one into a selectedcontent? I heard we're cloning into multiple soon.
<masonf> q+
<masonf> jarhar: for each selected option, you provide another selectedcontent, right?
<masonf> ...making a select with 5 options. Need 5 selectedcontent elements in the button?
<maikelkrause4> q+
<masonf> keithamus: yes.
<masonf> jarhar: you always need N selectedcontent elements, right?
<masonf> {scribe says ICK!}
<masonf> ack keithamus
<masonf> ...authoring expecting only 1, and you add multiple, and then you don't see them?
<masonf> ...you have to do extra stuff to the container, if you don't want the container. But I don't know when you don't want a container.
<masonf> maikel: defeats the point. Most of these are dynamic. No upper limit on the number of selections. Need scripting.
<masonf> ...feels like defeating the point.
<masonf> frehner: curious - silly idea: maybe default behavior is to show all of them concatenated together. But maybe selectedcontent has an attribute like summarize=true, and then you get "4 selected".
<masonf> ...still do most cases without a full override.
<masonf> q?
<masonf> ack frehner
<brecht_dr> q+
<keithamus> masonf: I want to push back against multiple selectedcontent, feels like a footgun, N option to N selectedcontent - someone comes later and adds more options and you forgot to add more.
<keithamus> masonf: in terms of number of added elements there are two approaches where you have to add an option to each element, the other one is wrapper div in each option - I prefer that, it's at least local
<keithamus> masonf: if I copy paste an option then I haven't shot myself in the foot
<masonf> q?
<keithamus> masonf: if we automatically build a wrapper element we're causing most developers to do more work. I'm conscious of that. If we do something it needs to not be more work to remove it.
<masonf> ack mason
<masonf> maikelkrause4: its a shame that Luke isn't here. I want to push back on whether this has to look nice in the first place, given that it's an opt-in.
<masonf> q+
<masonf> ...why does this have to look nice out of the box?
<masonf> ...another question: if we're exploring this automatic wrapping thing, it feels unnatural to create a div out of thin air.
<masonf> ...could the <option> be the wrapper?
<masonf> ...I don't know how the parser would treat this. Seems like a more natural container.
<masonf> ack maikel
<masonf> ack brecht
<masonf> brecht_dr: want to push back on that because it doesn't line up with existing single-select. Feels weird.
<masonf> ...for multiple selectedcontents - I'm not in favor of that also. What if I only want to show the first three. Add a wrapper div inside, and use ::nth-child in CSS.
<masonf> ...if I want to show a gazillion, just display:flex selectedcontent.
<masonf> ...just want it to be easy.
<keithamus> masonf: Personally, I don't care if it's ugly by default. Other browsers do care and we need to represent that position here. If it was me making people fix it up themselves with the opt in should be fine.
<keithamus> masonf: but with any styling at all should at least be usable. Right now it would be pretty bad, concatneating text without spaces
<jarhar> q+
<keithamus> masonf: if we have to through a magic wrapper thing, cloning the <option> as a wrapper might be the best option.
<jarhar> i dont think we should clone the option element
<keithamus> masonf: maybe an opt-in with `cloneouteroptions=true` or so. Opt in, less magic than divs out of thin air
<masonf> q?
<keithamus> masonf: might cause problems with other algorithms that expect options anywhere they live.
<masonf> ack mason
<keithamus> q+
<masonf> brecht_dr isn't that an opt-in inside an opt-in?
<masonf> masonf: yes.
<masonf> jarhar: I don't think we should clone the option itself, because it'll be a large amount of work to make them not act like options.
<frehner> or allow a div as a child of option that only renders when it's inside selectedcontent :D
<masonf> ...change all of the algorithms, etc.
<masonf> ...I'd much rather create a div out of nowhere than that.
<masonf> keithamus: same. We're one of the browsers that want base appearance to be functional. Maybe not the most attractive, but it should work as-is. Should be consistent. Appearance:none is for no styles.
<masonf> ...in select multiple, pseudo element between.
<masonf> qq+
<masonf> ack masonf
<Zakim> masonf, you wanted to react to masonf
<keithamus> masonf: if you just have options with text in them you can't put it on a text node.
<keithamus> q-
<jarhar> q-
<masonf> q+ sb3nder
<masonf> sb3nder: I think the concated text is less accesible when the text overflow the <select>, compared to what we have now.
<keithamus> ack sb3nder
<masonf> brecht_dr: there's a consensus that it will work with single selectedcontent, but the question is UA styles?
<masonf> ...anyone against a single selectedcontent, and all options gets cloned together?
<masonf> jarhar: I agree
<masonf> keithamus: agree
<masonf> keithamus: admit defeat and clone into selectedcontent
<masonf> keithamus: ...clone "3 selected options" text
<masonf> ...localized
<masonf> masonf: privacy issue reading back localized text?
<masonf> jarhar: use case is to keep all of the rich content
<masonf> keithamus: you'll use script anyway
<masonf> ...do what you'd do in script anyway, but make it easier avoiding the script.
<masonf> ...if it's just concatenating all of the options. If no wrappers supplied, you still have a lot of work to do.
<masonf> wrappers wrappers wrappers
<masonf> brecht_dr: rather than multiple selectedcontents, add wrappers. give them each colors. Would solve the UA stylesheet rules - the multiple seelctedcontent elements.
<masonf> ...feels like repeating yourself to have to have selectedcontents for each option.
<masonf> ...need to do something where you get to see all of the content, rather than "n selected options".
<masonf> keithamus: one way to fix this is to have fallback slotted elements, so when you change the size attribute, we create that many shadow slots.
<masonf> ...browser guarantees N where size=N
<frehner> allow selectedcontent to take a single child and use that as the separator between
<keithamus> masonf: Can we resolve at least on cloning the selected content and not the text of "n selected"?
<keithamus> masonf: perhaps we can enumerate the three options I think I heard: clone them altogether and you have to figure out the bits between yourself, magical wrapping where it wraps an element, and multiple selectedcontents where you provide the N selectedcontents
<keithamus> masonf: if those are the three can we eliminate ones we dont like?
<masonf> Three options: no magic, magic wrapping, or require N selectedcontents
<keithamus> q?
<masonf> keithamus: they all feel intractable.
<masonf> keithamus: unless you add wrapping, there's no way to figure out where one stop and one ends. Forces adding wrappers.
<masonf> q?
<masonf> Proposal: <selectedcontent autowrap>
<keithamus> masonf: skipping the 3, then the proposal is you opt in to autowrap which wraps each option in a div.
<masonf> keithamus: might be breaking
<masonf> brecht_dr: can we make them a list?
<masonf> ...kind of want a list of selected options. Could they become a list <ol> and each is a <li>
<frehner> <selectedcontent wrapper="IDREF"> <div class="wrapper" id="IDREF">
<masonf> ...makes sense from a11y standpoint, because you want them read as a list.
<masonf> jarhar: bad to stick a list inside a button
<masonf> ...unclear how to announce what's inside the button
<masonf> ...would want "N selected" to be the announcement. But Scott says it should be the contents of the list.
<masonf> keithamus: we've spent 50 minutes, we have another issue on the agenda.
<masonf> jarhar: I'm happy to move on.
<masonf> masonf: any resolutions?
<masonf> brecht_dr: that we want all of the option contents cloned?
<masonf> keithamus: how breaking would the opt-out be?
<masonf> Proposed resolution: <selectedcontent wrap={yes|no}> where the default is yes for multi-select, and no for single-select.
<masonf> keithamus: is there a slippery slope for which element wraps?
<masonf> sb3nder: proposed res: property on selectedcontent to make copy all content and concatenate, the wrapping is defered for a future resolution
<masonf> keithamus: I'd be against deferring wrapping, because it breaks the default experience
<frehner> q+
<keithamus> -1 to concatenate
<masonf> +1 wrap
<brecht_dr> +1 wrap
<keithamus> +1 wrap
<jarhar> i vote concatenate
<maikelkrause4> +1 wrap
<frehner> q-
<masonf> RESOLVED: <selectedcontent wrap={yes|no}> where the default is yes for multi-select, and no for single-select. Wrapper is a div or span.
<dbaron> It's possible div is better than span based on their default a11y behavior?

[lukewarlow]

Sorry I couldn't make this, my Spanish timezone made it too late.

Could someone give a summary of the resolution?

I'm quite keen that we make sure the default select with no slotted button is not just usable but actively not horrible. The current approach of n selected works well for that imo.

If we choose to do something different when someone explicitly uses button + selectedcontent that's probably more fine?

It does mean a UA can't just implement it like details where you provide a default button + selectedcontent inside a slot in your UA shadow Dom.

[mkrause]

Could someone give a summary of the resolution?

There seems to be a consensus that having the selected options content available in <selectedcontent> is desirable, but there's no agreement on the mechanism. Having some kind of opt in to get the individual selected options wrapped a container was supported to an extent (but needs further discussion).

[mkrause]

I'm quite keen that we make sure the default select with no slotted button is not just usable but actively not horrible. The current approach of n selected works well for that imo.

I understand this sentiment, but I also wonder how important it is though. A base-appearance <select> only exists when an author has already opted in to customizing a <select>.

So for instance: when we're discussing (as on the call) ways for authors to potentially opt in to getting a <selectedcontent> containing the multiple selected options content for easy customization, I don't see how it's different from the appearance: base opt in that the author already made.

[lukewarlow]

I understand this sentiment, but I also wonder how important it is though. A base-appearance only exists when an author has already opted in to customizing a .

Yeah, I guess I just forsee people doing.

* {
   appearance: base;
}

or even people who have already done

select {
    appearance: base-select;
}

And then wondering hmm why does this select look bad.

I could be persuaded this isn't a real concern but I'm not sure all vendors could be.

That's with just plain text in options, if we get options with even more stuff in I worry how it'll work.

Perhaps something where we need to prototype and see what we can do with it.

[frehner]

Silly ideas I didn't voice during yesterday's meeting, but want to put out just for fun 🤷 :

Add an IDREF attribute to point to another element that will serve as the cloned wrapper element:

<selectedcontent clone="ref"></selectedcontent>
...
<div id="ref" class="custom-styling"></div>

Another: Add a template element as a child of selectedcontent:

<selectedcontent>
  <template>
    <div class="custom-styling"> <slot></slot> </div>
  </template>
</selectedcontent>