Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

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

Closed
a2sheppy opened this issue Jan 26, 2018 · 7 comments
Closed

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

a2sheppy opened this issue Jan 26, 2018 · 7 comments

Comments

@a2sheppy
Copy link

a2sheppy commented Jan 26, 2018

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
Copy link
Member

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
Copy link

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
Copy link
Author

@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
Copy link

Nadya678 commented Jan 27, 2018

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
Copy link
Collaborator

chaals commented Jan 27, 2018

<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
Copy link

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

@chaals chaals self-assigned this Jun 19, 2018
@chaals
Copy link
Collaborator

chaals commented Jun 19, 2018

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

@chaals chaals closed this as completed Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants