Proposal: Allow adding separator rows to <select> boxes using <hr>

[a2sheppy]

There is no standard way to create a proper separator or dividing line within the box created using <select>. Currently, the most common solution is to just put some hyphens or emdashes in an <option> with the disabled attribute set. This doesn't actually look very good at all, and is not semantically accurate.

There's already a perfectly good element for creating horizontal dividing lines in HTML: the <hr> element. This should be allowed in the context of a <select> element in order to create separator rows.

This would let you then create a separator using <hr> within the <select>, like:

<select id="devicelist">
    <option value="none">None</option>
    <hr/>
    <option value="1903177618651917">Internal microphone</option>
</select>

In this situation, the <hr> is interpreted as a separator row and treated as such, rather than as a selectable option (since it's not an <option> element.

I've also filed this on the W3C spec: w3c/html#1156

[domenic]

Hmm. I'm not sure this is semantically accurate either; it feels more like a stylistic issue that you want to separate some options from each other. Do you think it'd make more sense to improve styling of option elements to e.g. allow you to add a bottom-margin or border for such separation purposes?

Anyway, this particular proposal is not possible, since the HTML parser discards the <hr> (and changing the parser is not generally done without extraordinarily good reason). See http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5769 for a demo.

If we were to try to solve this at a semantic level, we'd probably want to do it using some modification of optgroup, which is an existing semantic mechanism for grouping options.

[Nadya678]

The better solution is to add the full possibility to style the <select/>
w3c/csswg-drafts#2013

Then you will be able use border, margin and padding for the same effect or select option::after. The <hr/> in this case doesn't change theme of the document. Not semantic use.

I want to add not only lines between options but also change the frame of ::dropdown-list of the <select/>

[a2sheppy]

@domenic - That's a good point. That was actually going to be my follow-up proposal if this one didn't fly, to propose an amendment to <optgroup> to allow it to be used to create separators rather than named groups.

Since currently the label attribute is mandatory on <optgroup>, the obvious approach would be to simply make it optional, in which case the group is an unnamed one, separated from the previous and next groups (as applicable) by dividing lines or other platform-appropriate technique.

You could of course go a step farther and add, say, an optional type attribute that could override the browser/platform-defined behavior; something like

<optgroup type="divider" disabled>
    ... options ...
</optgroup>
<optgroup type="spacer" disabled>
    ... options ...
</optgroup>

The type would be used to indicate the type of separation above and below. In cases of conflict (such as above, where the first group wants "divider" and the second "spacer"), the top group wins.

[gsnedders]

https://codepen.io/tigt/post/separators-inside-the-select-element seems to have discovered this actually exists today in Blink and WebKit; this seems to date from 2005 (WebKit/WebKit@23dccec), though the parser side got broken at some point (probably with the HTML parser rewrite?), so currently it only works with DOM manipulation (and presumably XHTML? not tested).

[othermaciej]

To some extent separation of groups of options in a menu is semantic, not just style. When separators are used in native system menus, they are often used between groups of related items. So in that sense it's similar in meaning <optgroup>, except without a name. Based on that, I think either unnamed <optgroup> or <hr> as a way to get a separator would be better than using a fully general styling mechanism to add a margin or separator line to a specific item. Even with custom styling, adding style to an <hr> or a nameless <optgroup> would better express what is going on.

[zcorpan]

Indeed this is still supported in WebKit and Blink for both drop-down select and listbox select (<select size=4>). http://software.hixie.ch/utilities/js/live-dom-viewer/saved/10552

@whatwg/html-parser Is there interest in changing the parser to allow <hr> in select? Including making it imply an </option> end tag. I think it should be OK security-wise as it's a void element select throws away most tags.

[domenic]

Note that it's not supported on Blink on Linux at least... I wonder about Windows.

[zcorpan]

OK. I made a clearer demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/10554

Here's how it looks on macOS in Chrome:

Edge 103 on Windows 11 (tested with BrowserStack) also supports it:

[domenic]

Oh, yeah, I'm seeing it on Linux Chrome now; thanks. Weird that it's a blank space as a separator in listbox select.

[zcorpan]

On iOS Safari it's not supported:

On Chrome on Android the hr becomes its own selectable option!:

[zcorpan]

@annevk do you plan to add rendering support in iOS Safari?

[annevk]

I can't really speak to that. The feature is mostly optional, but can enrich the user experience when implemented and used.