[select] Removing the capability for the author to provide a datalist element

[josepharhar]

Now that we are planning to change the parser to basically allow any tag within <select> (perhaps except <input>), it's worth considering removing the ability for the author to provide their own <datalist> element since <select> already has the fallback one.

Allowing the author to provide their own <datalist> allows them to listen to popover related events and call showPopover/hidePopover on it directly. I'm having a hard time building something that really needs these. For example, I tried making view transitions work but I found that in general making view transitions work on a popover is way too hard.

The author can still target the fallback UA datalist with a pseudo-element, and it will be fully capable and support popover animations for example.

Can anyone think of a use case or capability that we need the author to be able to supply their own <datalist> for? If not, I'd like to remove this capability.

[josepharhar]

One other thing on this topic - from what I'm seeing so far, I don't think that changing the HTML parser to allow <input> inside <select> is going to be web compatible enough to ship.

I'm not proposing that <input> is allowed in <select> in the initial version of the new content model I'm proposing in WHATWG, so from that point of view this is no problem. However, for people who want to build things which we aren't sanctioning as accessible, they will have to use script to manually insert input elements into their selects. Maybe this is OK because it will nudge people towards building things which are accessible, and because those cases will probably need script anyway. If we find a way to make input elements accessible though in the future, we might have to re-introduce <datalist> or something though.

[mfreed7]

Just to clarify, if we resolve this issue the way you're requesting, this will still be allowed, right?

<select>
  <div class=container_for_styling_the_popover>
    <option>...
    <option>...
  </div>
</select>

[josepharhar]

Yes, that will still be allowed

[css-meeting-bot]

The Open UI Community Group just discussed [select] Removing the capability for the author to provide a datalist element, and agreed to the following:

• RESOLVED: remove <datalist> from the content model as an element that the author can provide in a <select>, because it doesn't provide any useful capabilities yet
• RESOLVED: remove <datalist> from the content model as an element that the author can provide in a <select> because it doesn't provide any useful capabilities yet

The full IRC log of that discussion

<dbaron> ScribeNick: dbaron
<dbaron> jarhar: This started when I was updating the explainer to remove <datalist> from some examples.
<dbaron> jarhar: with new parser changes, <datalist> not needed for most rich content
<dbaron> jarhar: it seems we don't need the <datalist> for anything at all if we have a pseudo-element the author can target for the fallback UA datalist
<dbaron> jarhar: further, allowing author to provide their own <datalist> *or* use the fallback one adds a lot of complications and machinery, such as making the datalist a popover without the popover attribute.
<dbaron> jarhar: if we were only using the fallback one we wouldn't need that
<dbaron> jarhar: in terms of capabilitiies, if we're making the parser allow anything, we don't need the datalist to opt in
<dbaron> jarhar: I tried an animation demo with the fallback datalist
<masonf> q+
<dbaron> jarhar: we need the :popover-open pseudo-class to work on the fallback datalist
<una> q+
<dbaron> jarhar: trivial to implement, not sure about spec'ing
<dbaron> masonf: mostly questions:
<dbaron> masonf: I already clarified that you can add a wrapper div or element to add a wrapper for your datalist -- that could, I guess, *be* a datalist element. You'd need to explicitly make it display:block
<dbaron> jarhar: yeah, that would still be slotted into the fallback datalist. Not sure if it's even a datalist -- the fallback popover.
<dbaron> masonf: there'd be a fallback popover in the UA shadow dom, containing a slot
<dbaron> jarhar: yes. That's what I've implemented. Anything that's not a button or option will be slotted there. options are a little more complicated...
<masonf> ack mason
<dbaron> masonf: so +1 from me
<masonf> ack una
<dbaron> una: generally not requiring datalist and letting the author decide on the containing element -- sounds great.
<dbaron> una: so in this example you'd have a div with a class that wraps options -- how does the parser know that's the popover?
<dbaron> una: so if you have 2 elements that are siblings, how does it know which are which?
<dbaron> jarhar: with what I'm proposing, the element inside the UA shadow root will be the popover. The author can't provide the popover anymore. You can target it with CSS, but can't access from script or provide it yourself.
<dbaron> jarhar: so if you have 2 divs they'll both be slotted inside the UA popover element.
<dbaron> una: if I have 2 divs, sibling div (too hard to scribe full example)
<bkardell_> q+
<dbaron> una: the button is not in the popover
<dbaron> una: can you have wrappers around the button?
<dbaron> jarhar: you can't have wrappers around the button
<masonf> q?
<dbaron> una: the button triggers it, and anything else goes in the popover?
<dbaron> jarhar: yes
<dbaron> jarhar: I couldn't come up with a compelling example where you need the author to have access to their own element that becomes the popover. The pseudo-element seems good enough.
<dbaron> jarhar: I looked into view transitions and it doesn't seem to help much.
<dbaron> una: one thing was a case of multiple popovers -- sub-popovers -- but I think it seems out of scope
<dbaron> jarhar: but I also don't see how this would limit you -- if you put another popover inside the select it will go inside the UA popover
<dbaron> masonf: and it will be in the top layer no matter what
<scott> so the following
<scott> <select>
<scott> blerp <img src=# alt=foo>
<scott> <selectedoption />
<scott> <button> [down arrow]</button>
<scott> <option>nerp</option>
<scott> </select>
<scott> would render as everything but the button inside the popup?
<dbaron> jarhar: if needed we could make the popover hierarchy code aware of this case
<masonf> scott: yes
<dbaron> una: my demos all still use datalist and they still work
<dbaron> jarhar: I haven't implemented this change yet, which is why the demos still work.
<dbaron> masonf: but the only reason it breaks is because datalist is default display:none
<dbaron> masonf: but it might also be ok to put a select > datalist { display: block} in the UA style sheet
<dbaron> jarhar: if we go forward this I'll simplify the content model to drop the concept of having a datalist
<scott> q+
<dbaron> jarhar: so I think replace your datalist with a wrapper div if you need it for styling
<dbaron> una: I think it simplifies the content model.
<bkardell_> q-
<masonf> ack dbaron
<masonf> dbaron: I think speccing the thing with the selectors shouldn't be hard, because it just depends on part-like pseudo elements.
<masonf> dbaron: once you hook into that concept, it's basically done.
<masonf> q?
<masonf> ack scott
<jarhar> q?
<dbaron> scott: I'm not opposed to this, just want to understand: if allowing people to use <datalist> is just removed, does that potentially roadblock the chance of in the future making comboboxes that open explicit dialogs or explicit grids? That was one of the reasons I wanted this. I understand the default would be a listbox of options because that's what it's been for 25+ years.
<dbaron> scott: The fallback is that that just goes into a popup is that browsers repair that, so we expose it as a dialog so people can search around for stuff.
<masonf> q+
<dbaron> scott: my hope there would be that in the future if you wanted a combobox that exposes a dialog you could declare that rather than making the browser guess.
<dbaron> scott: by taking this out now I'm not sure how it woud be put back in
<dbaron> jarhar: My understanding you previously talked about having the author put a dialog rather than a datalist -- we could still upgrade to a world where you do have a datalist or a dialog and you slot that in. But in this initial version I don't think it makes sense to propose extra machinery for something that's not used yet.
<dbaron> scott: my fear is that by not alluding to it we will close the door on it.
<dbaron> scott: but if you're not concerned about that then I won't be.
<dbaron> jarhar: If I can't make an example of how allowing the <datalist> introduces new capabilities, it's not clear why we have it.
<dbaron> jarhar: But if we make a new listbox primitive, or other explicit choice, we could still upgrade to that.
<dbaron> masonf: just a clarifying question to check that it's future us and not current us: if the developer puts things in the select that cause it to have to be exposed as a dialog rather than a menu -- the developer would say something in devtools that says we've changed it to dialog. And we say that to get rid of the warning you should put a dialog in.
<dbaron> scott: how can you warn people if [???] ?
<dbaron> masonf: I think either way the warning shows up.
<dbaron> masonf: I think if the browser has to switch it to dialog role it should have a warning.
<dbaron> masonf: But I think the warning just has to say not to use <select>
<dbaron> scott: I think it's ok for the initial release... but I'm worried that by taking this off the table it becomes harder to add in the future.
<dbaron> masonf: 2 ways to build that thing with extra content: one is to put a dialog inside the select and keep using select, or other is later on we introduce another new element for that purpose. Do we know if one is better than the other?
<dbaron> scott: I think many use cases are arguably other elements anyway.
<masonf> q?
<dbaron> masonf: combobox (free form text + suggestions) has been suggested, but I think it's a new element or new use of <input type=text>
<masonf> ack mason
<jarhar> proposed resolution: remove <datalist> from the content model as an element that the author can provide in a <select> because it doesn't provide any useful capabilities yet
<una> LGTM
<scott> +1
<keithamus> +1
<dbaron> RESOLVED: remove <datalist> from the content model as an element that the author can provide in a <select>, because it doesn't provide any useful capabilities yet
<jarhar> RESOLVED: remove <datalist> from the content model as an element that the author can provide in a <select> because it doesn't provide any useful capabilities yet