Content model and 'what' to render for stylable <select> elements

[scottaohara]

This is a follow on to #10310 to move discussion on what to do about the potential content models for styleable selects, and its current/proposed directly supported children/descendants (option, optgroup, hr, button, datalist). Additionally, I'd expect this discussion could also cover what may be rendered in a select or not, regardless of whether the elements are parsed out or not. (as was noted in the other issue, one can get around the parser and inject elements into a select - but they don't actually render. that's clearly not the intent for what changing the parser would do, continue to not have elements render - but maybe some still shouldnt?)

One reason to start this discussion is to also determine potential use cases / author intent for content that extends beyond the current content model. For instance, someone wanted to provide a description to an option element - they might think to intervene options with divs or paragraph elements to do this:

...
<option>Orange</option>
<p>A type of fruit, or color... context matters</p>
<option>...

but that isn't really enough to just allow the paragraph in there - there needs to be an association between the paragraph and the option so that the paragraph's content can be relayed via the a11y api as the options description. And putting the paragraph within the option means it'd contribute to its accessible name (undesired).

So, is it enough to just allow any content in and have authors hook it up themselves. Or have HTML determine new definitions for how elements work together in this context? Or is it really a new supporting element that is needed, and allowing main, article, video, iframe into the mix is just noise and potential for author error that didn't exist since the parser didn't allow these things before?

I hope this serves as enough to get this ball rolling.

[annevk]

To be clear, #10310 was to discuss a specific subset of #9799. What ends up getting rendered is really a function of the appearance property and is already tracked by its own issue over in the CSS WG: w3c/csswg-drafts#10028 & w3c/csswg-drafts#5998.

I think an accessible select will always need to have text-based options, essentially. Not just for accessibility, but also for platforms that opt not to support the custom rendering. When you create a tree that one cannot derive text-based options from (and thus doesn't render anything with appearance:auto instead of appearance:base-select) that should essentially be a non-conforming.