selectlist feedback from apple

[josepharhar]

I created a whatwg issue for selectlist here: whatwg/html#9799

I have been discussing with Anne in the issue and offline, and I have agreed with him to make the following changes:

1. Reuse the <select> element instead of creating a new <selectlist> element
2. Reuse the <datalist> element instead of creating a <listbox> element for this element

Reusing the <select> element will work because of the new content model that we switched to in replacement of the behavior/slot/part attributes. We can update the HTML parser to allow <button> and <datalist> to be children of the <select> element.

I think that there are more arguments to be made for or against <datalist> instead of <listbox>, but Anne seemed more in favor of reusing <datalist>. Since reusing <datalist> can certainly fulfill all of our usecases for the select/selectlist project and would make it easier/faster to ship, I am receptive to reusing <datalist>.

Depending on how additional improvements for <select> go, I could also see us ending up with something like <select size=n><datalist>...</datalist></select> becoming a standalone <listbox>-like thing which could be the aria-practices listbox which people have been interested in. I haven't gotten feedback on this idea yet though.

I'd like to get a resolution that these two changes are ok.

[lukewarlow]

I would want a concrete solution to the potential compat issue of people applying the multiple attribute in these case?

Would it be possible to use legacy select rendering (e.g ignore button and datalist) when multiple is set likewise for size attribute.

Would that actually solve the issue?

[josepharhar]

I think that ideally we will make this <button> and <datalist> pattern work somehow for <select multiple> and <select size>, but in any case we will have to make it work in some particular way before we get to that point and after we ship plain <select> improvements, so yeah I suppose there will be some compat risk in the intermediate period.

It would certainly be possible to use legacy select rendering when the multiple or size attributes are set, and I imagine that's probably what we would end up implementing.

[lukewarlow]

So some further questions:

• Would split button designs still work?
• What type do we give button (type="select"?)?
• How do we handle people being people and ending up with a select inside a datalist inside a select? (Yes this is in the HTML Spec https://html.spec.whatwg.org/multipage/form-elements.html#the-datalist-element:~:text=a%20select%20element%20inside%20the%20datalist%20element.)

[josepharhar]

Would split button designs still work?

I haven't gotten to this level of granularity with Anne yet, hopefully he and others are OK with it. The fact that github has these at the bottom of every issue and PR will hopefully make for a compelling argument.

What type do we give button (type="select"?)?

I also haven't talked with them about this yet. Not sure what the response will be, and I'm not proposing changing our views on it.

How do we handle people being people and ending up with a select inside a datalist inside a select? (Yes this is in the HTML Spec

Yeah this example in the HTML spec is pretty weird, not sure why it was added. So you're asking what happens if you do this?

<select>
  <datalist>
    <select>
     ...
    </select>
  </datalist>
</select>

I don't see how switching from listbox to datalist elements changes whatever weird behavior this makes, but I suppose that you'd end up with a select element inside the listbox...?

[lukewarlow]

I don't see how switching from listbox to datalist elements changes...

I guess difference is listbox doesn't have historical baggage of whatever the hell that is. Whereas datalist does. Was more just a hmm this'll need accounting for maybe

[css-meeting-bot]

The Open UI Community Group just discussed selectlist feedback from apple, and agreed to the following:

• RESOLVED: Reuse the select element instead of creating the selectlist element and reuse the datalist element for selectlist/select instead of using a new listbox element for it

The full IRC log of that discussion

<hdv> jarhar_: I recently created a WHATWG issue for selectlist and it got some feedback from Apple
<hdv> jarhar_: me and Anne from Apple discussed various things …one thing they suggested to change: to change selectlist to select, reusing the select element instead of using a new one… and instead of using the listbox element using the datalist element
<Luke> q+
<masonf> q+
<hdv> jarhar_: I agree with those and propose making those changes
<scotto_> q+
<hdv> q+
<dandclark> q+
<hdv> jarhar_: any questions?
<hdv> Luke: selectlist is nice because it has no historical baggage, but reusing select is nice because progressive enhancement… but need to be careful with multiple attr for instance, as we haven;'t figure out how multiple on selectlist would work
<masonf> ack Luke
<hdv> Luke: would we need to make a new element for multiple selectlist in case we realise it needs to something it currently can't?
<hdv> Luke: I like datalist instead of listbox, think it works, especially if you can combine size and multiple
<hdv> Luke: I do worry about the issues we could cause before it fully works
<hdv> Luke: if we just use HTML elements instead of slotted behaviours stuff that we had before, can it do all the things we thought it could before… also will we account for all use cases like split buttons?
<hdv> jarhar_: for select multiple we should be able to have the same improvements, hopefully there won't be issues with people using datalist with select multiple
<hdv> jarhar_: in this new proposal we would also avoid some of the parser issues that we had before with options in selectlist, where the content model was completely open ended; when we use select we would avoid those issues
<keithamus> q+
<hdv> ack mas
<hdv> masonf: I like this idea… was against it initially and feared it would be hard implementation wise… but it turns out there is a lot of parser behaviour that helps us a lot… the existing browsers/parsers will throw away all of the things it doesn't recognise, so we get a lot of leeway
<hdv> masonf: if we ship a version that doesnt support multiple for the new stuff… if you have a select multiple and throw in some of the new stuff, we could just make it fall back to an old style select multiple (it gives us great progressive enhancement)
<hdv> masonf: re q: if we can do the same with this new select proposal that we imagined for selectlist, the answer would be yes that should be possible (subject to jarhar_ going to be building all of this)
<masonf> q?
<masonf> ack scott
<hdv> scotto_: some of my questions were already answered… I think it's a good idea generally… it does make me wonder about some examples… like a split button that is a button and another button that opens a menu of sorts… in that case we could run in the situation that on macos that is mapped to a menubutton that opens a menu, but on Windows it opens a combobox… which is why it is hard to make a combobox...
<hdv> scotto_: ... that is consistent between Mac and Windows
<hdv> scotto_: this could perpetuate some of that
<hdv> scotto_: instead of being able to have a clean break, we may run into the issue where it is one thing in windows and another in mac
<hdv> masonf: the idea is that hte behaviour forks… you get the new behaviour if you do certain things, like add a datalist element in
<hdv> masonf: and only then
<masonf> q?
<hdv> masonf: so when 'the new behaviour' triggers in select we could do whatever accessibility mappings we wanted to do with selectlist
<masonf> q+ sasha
<hdv> q-
<hdv> scotto_: there's a lot of things a combobox can open, not sure how to do that anymore
<hdv> masonf: but this would be separate from combobox, more re select?
<hdv> scotto_: on windows combobox = select
<hdv> masonf: let's open an issue re these accessibility mappings
<hdv> masonf: we don't want to lose track of that
<hdv> ack dan
<masonf> ack dan
<hdv> dandclark: I like the idea… a couple of comments: parser changes scare me a little bit, all of these old parser hacks are in the HTML spec for a reason, people are probably doing stuff that we would also need to take into account
<hdv> dandclark: we probably need to make sure it doesn't break stuff
<hdv> jarhar_: would be happy to add deprecation warnings and stuff
<hdv> dandclark: what about feature detection, would there be a way to do that with the select situation?
<hdv> jarhar_: could check if selectedoption element exists
<hdv> dandclark: +1 to what Luke said about multiple, and there is another bag of attributes on select, like size and others, that we would have to double check, we had decided not to include them for selectlist
<hdv> dandclark: type attribute is not that useful but it is there
<hdv> dandclark: would be weird if you could have arbitrary content in there
<hdv> dandclark: caveats aside…it would be pretty cool if we could make this work
<masonf> q?
<hdv> jarhar_: ideally we could have sizes attribute or something else… and could have fully styleable listbox element like listbox element would have been if we had included that
<hdv> jarhar_: does the parser for @@@ throw away elements?
<hdv> scotto_: yes also for options, this needs to be very carefully checked
<keithamus> s/@@@/datalist
<masonf> q?
<scotto_> q+
<hdv> dandclark: would be prioritising the parser stuff
<hdv> Zakim, please close the queue
<Zakim> ok, hdv, the speaker queue is closed
<hdv> keithamus: thing about selectlist is that it is easier to polyfill… it would throw elements out right?
<hdv> masonf: I think the path here is more graceful degradation than polyfill
<hdv> bkardell_: do they throw them away or fix up?
<hdv> masonf: throws them away
<hdv> masonf: you could lots of things in a select that never shows up in the DOM tree
<masonf> q?
<hdv> sasha: hard to polyfill in the browser, for parser and runtime engine for customised and standard element
<masonf> ack keith
<hdv> ack sasha
<masonf> ack sasha
<masonf> ack scotto
<hdv> scotto_: regardless of parser issues… it just becomes easier to style select elements, I think that's going to be a win
<hdv> scotto_: does the work currently still have legs as a new proposal for a menu element?
<hdv> scotto_: a lot of what people wanted to do with this is create menus
<hdv> scotto_: there's arguably still a reason to do that… a lot of what we're doing here is potentially reusable for menu-like element too
<hdv> scotto_: so if select has to be used… that could be a way to make it easier for people to make that styleable. And then what selectlist was, there was a lot of use cases that belonged in the menu category
<hdv> +1!
<keithamus> +1
<jarhar_> Proposed resolution: Reuse the select element instead of creating the select element and reuse the datalist element for selectlist/select instead of using a new listbox element for it
<jarhar_> Proposed resolution: Reuse the select element instead of creating the selectlist element and reuse the datalist element for selectlist/select instead of using a new listbox element for it
<keithamus> +1
<hdv> +10
<Luke> +1
<dandclark> +1 to trying it
<keithamus> +∞
<jarhar_> RESOLVED: Reuse the select element instead of creating the selectlist element and reuse the datalist element for selectlist/select instead of using a new listbox element for it

[github-actions]

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.