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.

This has also been filed against the WHATWG spec: whatwg/html#3410

[scottaohara]

What would the purpose of the hr be outside of a visual separator? Is it to group options into different sections? Would using optgroup and conveying the purpose of the separation be more appropriate?

[Nadya678]

I think there should be possible to fully style the <select/> field including options and listbox. Here is my proposition for it w3c/csswg-drafts#2013.

[a2sheppy]

@scottaohara - The primary purpose would indeed be as a visual separator. Just to break up the "big blob of items" you get without some form of separation periodically. Additionally, there are platforms where titled groups are not a standard interface feature in a selection box or popup (or even a non-standard one; they're just not done, outside the context of a web browser). Allowing simple separators would make compliance with those sorts of interface standards much easier to do attractively.

@Nadya678 - That's an interesting proposal, but it's a fairly substantial change, especially on browser/platform combinations where the interface used for is not generally flexible enough to implement that degree of customization. Even on those platforms, though, there is just about always the ability to add some form of separator or spacer row.

[Nadya678]

I think, all browsers that is able to show majority part of CSS3 are able to show the element. I wrote the <datalist/> customizing JS compatible with Firefox, Chrome and IE11/EDGE without:

• adding any additional container - <datalist/> and <option/> styled directly thus in web browsers with GUI it is possible also for <select/> field.

• without replacing any element.

• without detection of browser.

The input+datalist is similar to combobox field (the datalist and option customization is also proposed by me). Browsers doesn't have to use the native system controls. Part of statements (like <optgroup/>s) are not supported by native controls (COMBOBOX) in Windows but... should work.
Almost all browsers implement own controls and are able to reimplement them to meet our specification.

[chaals]

<hr> fgeels like it is semantically right, but problematic because it means changing parsing and that means getting browser buy-in.

Stylable form controls are a common request, but there has not been much in the way of making it happen generically - even custom elements have problems for the moment.

So something like an optgroup with a label of "------" is probably going to be with us for quite a while :(

There are various approaches to this issue. You might want to move it to the Web Platform Incubator Group for the time being and see if one gets some traction...

[Nadya678]

@chaals can you also move my topic to the web platform incubator group?

[chaals]

Discussion in the HTML meeting (pointer to just after the discussion) decides that this is a layout issue, and hr is the wrong solution.

Closing