[Selectlist] Include `<hr>` as an allowed child of `<listbox>`

[YummyBacon5]

trafficstars

The hr element is allowed as a child with a normal select element. Its use is to create a separator.

But it seems that this is not included with selectlist.

I think that it should be allowed for use with the listbox slot/element.

Although, currently, a hr is not allowed as a child of an optgroup (https://github.com/whatwg/html/issues/9247), so should it be allowed as one here?

[scottaohara]

agreed that it should be allowed for parity purposes. but really, i find it to be practically of little value since the new selectlist will be more styleable.

re: https://github.com/w3c/html-aam/issues/480 - i haven't done anything with that issue since there's nothing to really do with it, since someone navigating through the listing of options would never be able to get to it (focus it with keyboard, navigate to it with a screen reader) anyway.

honestly, if it's meant to represent the breaking up of options to be in different groupings - then optgroup should be used instead and that can be styled to just have a single bottom border. then more meaningful semantics could be exposed, since there would be clear groupings created, rather than assumed groupings per the inclusion of the horizontal rule, where was that done because the author really wanted to make these into groups, or because they're using the element for styling purposes?

[josepharhar]

<hr> currently works in the prototype: https://jsfiddle.net/jarhar/pka837jd/2/ We don't really disallow any elements in <listbox> at the moment as per https://github.com/openui/open-ui/issues/540 Is there any action we should take here?

[lukewarlow]

I guess maybe add some mention to the explainer. But otherwise I guess there's nothing that needs doing?

[josepharhar]

Hmm if we added any sort of note saying that <hr> is a supported child/descendant of <listbox>, then I'm worried that would imply that other elements like <div>s aren't supported, even though they actually are.

The reality is that everything is supported, but putting interactive elements in there is bad for accessibility and we will generate console warnings etc. when that happens. When we create a separate explainer for <listbox>, I intend to make that more clear.

[scottaohara]

"supported in that anyone can put anything into it and the parser won't kick it out" vs "supported because they have semantics specific to this element that don't require you to wire things together" are pretty different though.

i'm not particularly convinced that adding hr to select elements is the most useful thing that could have been done. but since these (selectlist) popups will rendered differently than the OS-provided popup, there is more opportunity for these to be discoverable / possibly some more thought of how they could be exposed in a useful way could be made to people using screen readers, for instance.

[lukewarlow]

I think it's worth calling out even if it's just 'selectlist like select supports hr, but so is everything else so have at it'

[YummyBacon5]

I first opened this issue since I thought the anatomy was the content model of <selectlist>, but it wasn't lol.

So a section, in the explainer, of what is allowed as a child of what would be helpful.

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

[lukewarlow]

Given we're using select now we might get this for free?

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

[scottaohara]

since hr is supported in the content model, since this ended up building off from select, i'm going to close this issue.