[selectmenu] Reconsider requiring <listbox> as a prerequisite for <selectmenu>

[dandclark]

A while back we discussed #447 about how to handle <select multiple>, and resolved that this question should be settled through specification of a <listbox> element supporting single and multi-select. This element would then be used as <selectmenu>'s listbox, and could also be used as a standalone element on the page (similar to <select> today with size attribute > 1).

I think we should reconsider this resolution in order to rein in the scope of V1 <selectmenu> to something that is spec-cable and implementable in a reasonable timeframe. A separate <listbox> element introduces a lot of complexity and seems to be an inversion of priorities given the clear developer demand for a customizable <select> vs that for <listbox>*.

Having <listbox>/<selectmenu> as a compound control introduces new issues that don’t currently exist in the platform. In order to be useful as a standalone element on the page, <listbox> will need to have the full set of APIs associated with form controls (value, disabled, checkValidity(), etc), and will need to be able to participate as part of a <form> on its own. But when a <listbox> is used as part of a <selectmenu> we would need to decide how the <listbox>’s state is exposed. Does it still have its own value property, and is its value included separately in form submission? Does it still run its own form validation, or does it delegate to the <selectmenu>? What happens if the <listbox>’s disabled attribute is set, and the <selectmenu>’s is not, and vice versa?

In short, the use of <listbox> together with <selectmenu> makes using <selectmenu> more complicated for both web developers and for browser implementers without adding any clear value aside from, perhaps, semantic clarity. There is no benefit for <listbox> in terms of accessibility, since the platform can assign the proper a11y roles to <div behavior=”listbox” popup=”popup”> when used as the <selectmenu>’s listbox, the same as if <listbox> were used.

If, however, we wanted to add a <listbox> element to the platform sometime in the future, <selectmenu> could be updated to allow authors to slot it in as a custom listbox part, as an alternative to <div behavior="listbox"> (once we’ve worked through the aforementioned spec complications). Controller code in in the <selectmenu> could ensure that the following have the same appearance and behaviors:

<selectmenu>
  <div slot="listbox" behavior="listbox" popup="popup"> 
    <option>Thing one</option>
    ...
  </div>
</selectmenu>
<selectmenu>
  <listbox slot="listbox" behavior="listbox" popup="popup"> <!-- or maybe behavior="listbox" could be implicit here -->
    <option>Thing one</option>
    ...
  </listbox>
</selectmenu>

The styles and controller code in the shadow DOM would ensure that <listbox> has the same default appearance and mouse/keyboard interactions as <div behavior="popup"> regardless of how <listbox> behaves as a standalone element. For the same reason, the default listbox part in the <selectmenu>'s user-agent shadow DOM could also be converted from a <div behavior="listbox"> to a <listbox behavior="listbox">. The value of doing so is not clear, though, since such a conversion would be opaque to authors. They can't directly reference the default listbox part via script, and there would be no change in appearance or mouse/keyboard interaction as per the above.

Regarding the original question of what to do for multi-select, I propose that we simply punt on this for now. The point of doing so is, again, to scale back feature creep around <selectmenu> and scope it to a manageable core that will meet the developer demand for a customizable <select>.

It can be added in the future with minimal compat risk if we just have the multiple attribute (<selectmenu multiple> and <div behavior="listbox" multiple>) do nothing for the time being, and perhaps emit a console warning. The multiselect functionality can then be lit up later either with an attribute or with a new element.

* @mfreed7 pointed out to me that demand for a <listbox> with multiselect might be lower than it appears from usage statistics due to how badly the current <select multiple> works today. I think however the expressed developer demands still points to customizable single-<select> being the number one priority.

[scottaohara]

just commenting to +1. Definitely agree this is the right way to go at this point, and just going to reference that my thoughts on if a listbox element is even needed have changed, as I mention in #487.

one question i have though:

a <listbox> with multiselect might be lower than it appears from usage statistics due to how badly the current <select multiple> works today.

what was surveyed to determine this? the reason i ask is because if <select multiple> was the element surveyed, then i'd agree that those numbers are probably low. but if say a custom ARIA combobox > listbox popup with aria-multiselectable was surveyed, well... i can point you to a metric ton of these :(

[mfreed7]

Also commenting mainly to +1 this. As the OP points out, these do seem to be separable designs (select-single vs. select-multiple) and I'd like to make sure we don't block the former on the latter. We'll certainly learn a lot from the initial <selectmenu> element that we can apply to <selectmenu multiple> or <checkboxgroup> or whatever.

a <listbox> with multiselect might be lower than it appears from usage statistics due to how badly the current <select multiple> works today.

what was surveyed to determine this? the reason i ask is because if <select multiple> was the element surveyed, then i'd agree that those numbers are probably low. but if say a custom ARIA combobox > listbox popup with aria-multiselectable was surveyed, well... i can point you to a metric ton of these :(

I think you're right. This statement refers to the Chromium use counters, which show 16% of page loads using a single-select, and 0.4% of page loads using a multi-select. But as you point out, that's likely undercounting the true usage. But I think (?) we'd all agree the usage of single-select is at least greater than the multi-select, right?

[scottaohara]

But I think (?) we'd all agree the usage of single-select is at least greater than the multi-select, right?

absolutely agree.

[gregwhitworth]

I am truly torn on this, as I think there is enough utilization across the web of listbox solutions that we'll need to produce one and it'll be a relatively 1:1 to what behavior=listbox.

That said, I understand the pragmatism and the listbox being slottable is a nice escape hatch. Again, not necessarily thrilled from a purist POV but won't push back strongly on this.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Reconsider requiring <listbox> as a prerequisite for <selectmenu>, and agreed to the following:

• RESOLVED: <listbox> and multi-select are worthwhile and we'll eventually work on them, but the V1 of <selectmenu> will not use a <listbox> element and will not support multi-select.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Reconsider requiring <listbox> as a prerequisite for <selectmenu>
<gregwhitworth> github: https://github.com//issues/531
<gregwhitworth> dandclark: setting the context for this one, we discussed a different situation for select multiple
<gregwhitworth> dandclark: the resolution we took was that we should specify a listbox element would support single and multi-select
<gregwhitworth> dandclark: this would be used by select and by itself on the page
<gregwhitworth> dandclark: similar to what you get now if you set size greater than one
<gregwhitworth> dandclark: today I want to reconsider that resolution as it's a large increase in scope
<gregwhitworth> dandclark: listbox to be an element itself needs its own events, validation, form involvement, attributes, etc
<gregwhitworth> dandclark: if we then allow authors to slot in the listbox then we have 2 sets of these which then raise their own conflict questions
<gregwhitworth> dandclark: there are a whole bunch of pitfalls here but it does increase the potential for developer confusion
<gregwhitworth> dandclark: we've ended up priority inversion
<gregwhitworth> dandclark: specifying all of this will take a lot of time
<masonf> q?
<gregwhitworth> dandclark: when we started this gregwhitworth had data that showed selectmenu was what they wanted to get created and so I want to escape from this priority inversion if we can
<masonf> q+
<gregwhitworth> dandclark: selectmenu will continue to work as defined but it will just be a div. If we wanted to create a listbox down the road then they would need to slot in the listbox element
<gregwhitworth> dandclark: it can behave the same way but it's just a semantic convenience, the nature of the controller code allows us to slot it in
<gregwhitworth> dandclark: for select multiple I'm still recommending that we punt on multiple but it shouldn't block a styleable/extensible single selectmenu element
<gregwhitworth> ack masonf
<gregwhitworth> masonf: +1 with a slight tweak to the resolution which is to denote that both of these things are important but we want to be iterative and get feedback on the simpler solution early on
<scotto_> q+
<gregwhitworth> masonf: I did have forward compat issues but you've alleviated that
<una> q+
<gregwhitworth> scotto_: I completely agree with this resolution and the variation that masonf added in there
<gregwhitworth> scotto_: it will be useful but I don't see why it needs to hold up the simple case and allow authors to do more complex things over time
<gregwhitworth> ack scotto_
<gregwhitworth> ack una
<gregwhitworth> una: I agree it, land it to get it right and reduce complexity - and I dont' want the resolution to say "may" add it in the future I want the resolution to be clear that we need them
<gregwhitworth> q+
<dandclark> Proposed resolution: <listbox> and multi-select are worthwhile and we'll eventually work on them, but the initial version of <selectmenu> will not initially use a <listbox> element and <selecmenu> will not support multi-select.
<una> gregwhitworth: second what everyone else said
<una> gregwhitworth: we also still need solution (HTML or CSS) that falls back to styles -- battleship grid
<dandclark> edited Proposed resolution: <listbox> and multi-select are worthwhile and we'll eventually work on them, but the initial version of <selectmenu> will not initially use a <listbox> element and <selectmenu> will not initially support multi-select.
<una> gregwhitworth: we need UA defined styles to make them interoperably stylable
<tantek> +1 gregwhitworth
<masonf> See: https://github.com//issues/536
<masonf> +1 to proposed resolution
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<dandclark> wordsmithing Proposed resolution: <listbox> and multi-select are worthwhile and we'll eventually work on them, but the V1 of <selectmenu> will not use a <listbox> element and will not support multi-select.
<masonf> +1
<gregwhitworth> RESOLVED: <listbox> and multi-select are worthwhile and we'll eventually work on them, but the V1 of <selectmenu> will not use a <listbox> element and will not support multi-select.
<tantek> no objections, though waiting to here from emilio

[dandclark]

Closing this based on the above resolution.