Design the `<listbox>` element

[josepharhar]

The new architecture for <selectlist> has a <listbox> element now that we aren't using the behavior or slot attributes anymore. @mfreed7 suggested that it would be a bad idea to ship <listbox> for <selectlist> without defining what <listbox> does outside of <selectlist>, so I think that we should ship standalone <listbox> ahead of or along with <selectlist>.

From my point of view, anything we need to figure out to make standalone <listbox> work well is also a problem for <selectlist>, so I don't see this being a huge amount of work.

This goes against the resolution made in https://github.com/openui/open-ui/issues/531

I'm happy to create an explainer etc for <listbox> if everyone is ok with this. I already started one here: https://github.com/josepharhar/explainers/blob/main/listbox.md

[lukewarlow]

As I mentioned in https://github.com/openui/open-ui/issues/836 I'm very supportive of speccing a listbox element alongside selectlist. I fear if we don't we'll end up with compat issues in future where people have used it outside of selectlist and now it suddenly does something. I think the decision to no longer use slots invalidates #531's resolution.

[scottaohara]

One point of clarity which would be helpful is around whether this would default to selection following focus or not.

The APG examples have selection follow focus (though its listed as 'optionally' in the documentation of the keyboard behavior).

The current select size=1+ similarly has focus move to the listbox container, and then up/down arrows 'focus' the options within, where selection follows.

A drawback to this is that similarly to radio groups, once a selection has been made, it can't be undone without a form field reset.

So the choice here seems to be to stick with current functionality, or to go the route of selectlist and not have selection follow focus. (maybe even allowing someone to deselect an option?)

[lukewarlow]

I would like this to follow selectlist and NOT follow focus. For two main reasons, I think consistency is key for these new elements to take off and having them behave the same will be a big boost to DX (and UX imo). Secondly, especially for the multi select case I separating focus and selection is much nicer DX. At my last role we spent quite a while playing around with the selection of multiple items case and not following focus won out.

[scottaohara]

Per the linked gist, is the idea to have listbox allow the multiple attribute, or is the idea to still maybe create a separeate element for multiple selection?

i don't have strong opinions either way on that, but multi-select UX is really awkward with current listboxex. we can absolutely do better than current behaviors (and would second the points @lukewarlow raises in the previous comment on this topic).

[lukewarlow]

We don't have to overload the speccing of this up front cause I know it'll probably get complicated, But being able to use listbox for the duallistbox paradigm (#878) would be handy too just as something to be aware of.

[josepharhar]

Per the linked gist, is the idea to have listbox allow the multiple attribute, or is the idea to still maybe create a separeate element for multiple selection?

I think we should create a separate tag name for multi-select. At the very least, supporting the switching of modes in the browser is not good. I asked about this in the whatwg matrix chat and people seemed to agree that a separate tag name would be better and that <input type=foo> has caused issues. I can attest that the machinery to do this in chromium is... big.

One point of clarity which would be helpful is around whether this would default to selection following focus or not.

Yeah for the sake of selectlist, making selection not follow focus would be ideal. I think that if we end up implementing default checkmarks, then this is acceptable since you should clearly be able to see that the selected option didn't change. If someone comes by and explains that making selection follow focus is the most important thing ever, then perhaps we could add an attribute to opt in to selection following focus or something...? I wonder what the screenreader experience is like for these behaviors, for selectlist or listbox.

[scottaohara]

I wonder what the screenreader experience is like for these behaviors, for selectlist or listbox.

well... heh, that's why i keep asking about if selection will follow focus or not - because the behaviors are currently aligned to the fact that selection has historically followed focus for the select element options. And, because there is no standard for how screen readers have to expose information to their users, the way the current selected state of an option is announced to people is variable.

For instance, some screen readers will announce if an option is 'selected' but not if it is 'not selected', while others will take the reverse and only announce the not selected state and are silent on the selected state (because implicitly it was known that if someone was focused on an option, then it had to be selected - so why repeat that... well unless some people were going to create a new version of the element to uproot this notion?)

jokes aside, this sort of variability in the selected state is a pain point for some people with custom implementations of ARIA comboboxes/listboxes. and this / along with the fact people have been using selectlist to create what would be described as Menus (not a criticism of anyone - it's a common crossing of wires) has me wondering if maybe some of this could be resolved by changing the role mappings for this new element/its parts.

https://github.com/w3c/aria/issues/2050 https://github.com/w3c/aria/issues/2067

[css-meeting-bot]

The Open UI Community Group just discussed Design the `<listbox>` element, and agreed to the following:

• RESOLVED: Create an explainer for and incubate the design of a listbox element

The full IRC log of that discussion

<gregwhitworth> q+
<flackr> q+
<masonf> q+
<keithamus> jarhar: I suggested <listbox> to replace the slot=listbox. There's now interest of using outside of <selectlist>. Any problem encountered will be applicable to standalone, so we should figure out how to make it standalone, then use it for <selectlist>. I'd like us to go make an explainer, happy to do it.
<keithamus> gregwhitworth: we've been working on combobox explainer, so +1 here. When we worked on extensible select, insetting select - listbox enabled this. Really like it.
<gregwhitworth> ack gregwhitworth
<keithamus> flackr: whats difference between select multiple and bare listbox?
<Luke_W> q+
<keithamus> gregwhitworth: purposely wasn't bringing up multiple... there's a bunch of nuance with listbox we need to talk about, Joey wants to scope it to listbox.
<gregwhitworth> ack flackr
<gregwhitworth> ack masonf
<keithamus> flackr: maybe listbox is visualisation, selectlist is data container. I'm supportive of the idea of abstracting
<gregwhitworth> +1000000 to Mason's point
<scotto_> q+
<gregwhitworth> ack Luke_W
<keithamus> masonf: resolution is make an explainer? I'm supportive. Big fan of incremental shipping. selectlist is the largest thing to hit html maybe ever? My fear is listbox element might a giant project which may delay selectlist by years. I want to register that we're okay to have the flexibility to go back to selectlist only that doesn't work outside. In
<keithamus> favor of going forward with explainer just don't want to lock us in
<masonf> q++
<masonf> ack +
<gregwhitworth> q+ argyle
<masonf> q+
<keithamus> Luke_W: I agree. Let's not make it a blocker. We should spec out a standalone listbox- if we don't someone will put it elsewhere, it won't render, and if we ship in future that becomes a breaking change. Select multiple I see as select with size. Multi select is something we do down the line. We discussed it before about being a separate element.
<keithamus> If we're okay with listbox being single select, we can come up with an explainer to keep it narrowly focused and keep in mind compatibility.
<gregwhitworth> ack scotto_
<keithamus> masonf: its not a solution to have it not work outside, you can put elements anywhere, either it works or it doesn't.
<masonf> ack masonf
<gregwhitworth> q+
<keithamus> scotto_: I agree this needs to be done. Latest message back from html standards was not repeating html elements. What problem are we solving apart from styleability? I can think of a few. We can solve some problems here. Big +1
<gregwhitworth> ack argyle
<jarhar> q+
<keithamus> argyle: I wanted to see what happened with it outside <selectlist>. It loses stuff but it works. It gets fuzzy for me though - they're options without a target? Keyboard focus? Does it trap, like dialog? It opens a lot of questions. It needs to contain and operate in its own new way. What's its detached behavior? Maybe it doesn't need much -
<keithamus> datalist doesn't. But what does it do?
<masonf> q+
<argyle> yeah, <options> cant just float, they need a container
<keithamus> gregwhitworth: I dont think multiple should be an attribute on listbox. Are we trying to say "here is the semantic meaning of this container?" which may or may not change based on its containing element. Selectlist and combobox will behave quite differently even though they contain a listbox. There's so many questions. Is anyone on the queue to
<keithamus> oppose an explainer? No?
<keithamus> q?
<gregwhitworth> ack gregwhitworth
<jarhar> proposed resolution: Create an explainer for and incubate the design of a listbox element
<keithamus> +1
<Luke_W> +1
<masonf> +1
<jarhar> RESOLVED: Create an explainer for and incubate the design of a listbox element
<gregwhitworth> ack jarhar
<gregwhitworth> ack masonf
<keithamus> jarhar: the questions all raised.. I am hoping aria gives us answers to these. It maps to listbox role, I hope it gives us answers to these questions.
<keithamus> masonf: there's more than just aria? listbox is form associated no? People bought up datalist - this has been the backup plan. There's no world where listbox is like datalist; so maybe the backup plan is to make datalist the element - which already has the "renders nothing" behavior.
<keithamus> gregwhitworth: is there a spec?
<keithamus> jarhar: no spec yet.

[josepharhar]

Thanks for the feedback @scottaohara, I moved it into a separate issue: https://github.com/openui/open-ui/issues/910

[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.