5 ms·

Bringing Back Horizontal Rules in HTML Select Elements

192 points by ingve 3y ago

deleted 3y ago
[deleted]
OJFord 3y ago
TFA mentions `optgroup` too, wouldn't it make more sense to use that and style it similarly? Especially if `hr`-in-`select` is only going to work in Safari anyway(?).
- chrisb 3y ago
  The article isn't completely clear; but hr-in-select is standardized [0] - and it definitely works in the Firefox v122.0 I'm browsing with. [0] https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element https://html.spec.whatwg.org/multipage/form-elements.html#th... (see the "Content model" line)
  - OJFord 3y ago
    Pfft I'm an idiot - I'm reading from (and tried it out with) Firefox too!
    - genezeta 3y ago
      It's been added in 122.0 [0], but it wasn't working previously. [0] https://www.mozilla.org/en-US/firefox/122.0/releasenotes/#note-789971 https://www.mozilla.org/en-US/firefox/122.0/releasenotes/#no...
      - OJFord 3y ago
        I'm using latest FF, it did work, I said I was an idiot because despite seeing it work, trying it out in a non-Safari browser, I came here and wondered aloud if it would work other than in Safari!
  - deleted 3y ago
    [deleted]
- lapcat 3y ago
  Optgroup has a mandatory label attribute.
- vinnymac 3y ago
  Not to mention the user experience for an optgroup on mobile is vastly superior as a sheet rather than a popover. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se... For those without iOS, see an example here: https://ibb.co/DkN16Gc https://ibb.co/DkN16Gc
  - Pesthuf 3y ago
    <select multiple> on mobile devices is so good - why don't the finally improve the implementations on the desktop as well? The arcane 90s UI paradigm it currently uses everywhere just doesn't work. And please, just give us an attribute that adds a search bar... I don't want to use 30 KB of JavaScript just to have selects that feel like they're from this millennium, especially since those then don't work too well on mobile…
    - extra88 3y ago
      That's a text input plus a datalist. Their browser implementations also have some issues but can do the job.
      - moron4hire 3y ago
        There's a whole other ball of problem wax with input plus datalist. The options don't appear again if one has been selected already; the user first has to clear the input and then the list appears. Also, the input can't be strictly limited to the options in the datalist; the user could type in whatever they want and it's still "valid" and fulfills any required attribute added to the tag.
    - carlosjobim 3y ago
      > And please, just give us an attribute that adds a search bar... That's the datalist html element.
    - int_19h 3y ago
      What is "arcane" about the desktop multiple selection paradigm? It has been the standard way to deal with selections in all desktop OSes for decades now.
- shiomiru 3y ago
  Agreed, this just looks like a non-accessible <optgroup> alternative and feels like a step backwards. I fear authors will now use hr instead of properly grouping their elements, to the detriment of screen reader users. Why not just make horizontal rules between optgroups the default?
vinnymac 3y ago
> You could still see it by manipulating the DOM or using XML, but apart from a couple of experts nobody knew. Except for all the users who were frustrated by the change. Most users wouldn’t even know who to report this to, even if they noticed it at all. They may chalk up the issue to the new computer or phone they purchased in the last two decades.
lapcat 3y ago
For me the problem is that iOS already adds horizontal rules between all select options, so the new feature doesn't make any sense there, and I can't share code between Mac and iOS. I wonder if anyone on the WebKit team looked at the blog post example in Mobile Safari?
- eyelidlessness 3y ago
  It doesn’t render an extra separator on iOS, so you should be able to use the same markup.
  - lapcat 3y ago
    I think you're missing the point. The redundancy of the <hr> on iOS means that on iOS the <hr> doesn't serve its purpose of separating the options.
    - eyelidlessness 3y ago
      I was responding to your point that you can’t share code between the platforms. It doesn’t have the same presentation, but it’s no less usable with the <hr> than without.
      - lapcat 3y ago
        > it’s no less usable with the <hr> than without. Sigh, you still don't seem to get it. The point of code is to provide functionality to the user. If I want to visually separate the options, the <hr> on iOS does not provide the functionality. Thus, I need to do something else on iOS in order to visually separate the options, and thus I can't share the <hr> code with other platforms. "no less usable" is a misleading way of phrasing the problem. The <hr> on iOS is not usable at all as a visual separator between options in a select element. It's pointless, with no use.
        eyelidlessness 3y ago
        I’m responding from a perspective of over two decades of web development. It’s a necessary reality of the web as a platform that different rendering environments have different capabilities, and this is a fairly typical case of/for graceful degradation.
superhumanuser 3y ago
Doesn't work on Android. Every option has line below it.
- neogodless 3y ago
  I'm on Android and see no lines at all. (Firefox)
- ahoka 3y ago
  It does not work on iOS either :)
squigglydonut 3y ago
Let's get chrome support
- grishka 3y ago
  It does show the separators for me on Vivaldi (which is Chromium-based)
- throwaway290 3y ago
  It works in v120.
  - kps 3y ago
    119 — https://developer.chrome.com/blog/hr-in-select/ https://developer.chrome.com/blog/hr-in-select/ is linked from the OP article, but not prominently.
- squigglydonut 3y ago
  Chrome android
PaulDavisThe1st 3y ago
Another fabulous example of "since we're now aiming to implement 90% of new GUIs in the browser, let's take a couple of decades to slowly add each and every element of desktop native GUI toolkits from the 1990s". Sigh.
- deleted 3y ago
  [deleted]
- lazypenguin 3y ago
  Every time I read a recommendation for webview/tauri/electron/etc. I always ask myself “what about datagrids, docking tabs, context menus, etc.?”
  - deleted 3y ago
    [deleted]
- akira2501 3y ago
  GUI toolkits never had to be designed and implemented by committee, so they have the speed advantage. On the other hand we've got a "custom elements" implementation that's far more ergonomic and implemented across all platforms, some of them even let you play with the "internals" mechanisms, and all if it is better than I remember any GUI toolkit providing.
uses 3y ago
i had no idea <select multiple> existed. it works great on my ipad and has great browser support. https://caniuse.com/mdn-html_elements_select_multiple https://caniuse.com/mdn-html_elements_select_multiple
- ErneX 3y ago
  Since 1995 (HTML 2.0) https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.3 https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1....
  - teddyh 3y ago
    I believe the canonical spec for HTML 2.0 is actually RFC 1866: <https://www.rfc-editor.org/rfc/rfc1866#section-8.1.3 https://www.rfc-editor.org/rfc/rfc1866#section-8.1.3>
- bdcravens 3y ago
  It's always been there, but for traditional browsers, it was tedious: Ctrl/Cmd + click. Many non-power users found it tricky or didn't know about it, so we all more or less settled on checkboxes as a UX standard.
alexfromapex 3y ago
Wish browsers would start shipping a sensible multi-select. There’s one now but it’s not user-friendly enough IMO.
- jareklupinski 3y ago
  i built one a bit ago using an event (onselect or onchange?) handler on a regular dropdown that, when you click on an item, the handler removes that element from the dropdown options, and adds it to another ul/li list under the dropdown, with a little X to reverse the process select2 does something similar but yea it's weird this isn't a built-in maybe a dropdown with checklists?
  - config_yml 3y ago
    > maybe a dropdown with checklists? That's builtin with <select multiple> but it's only usable on mobile.
- asddubs 3y ago
  And one with drag and drop reordering. or at least some form element that allows drag and drop reordering (ideally of arbitrary markup blocks)
c-smile 3y ago
I do not really understand what is the problem with flexible <select> implementation in browser. In my Sciter[1] the following are supported ( see screenshot [2] ): <select type="dropdown"> - select with popup <select type="list"> - select list <select type="tree"> - hierarchical select (a.k.a. tree view) and all of them may have <select multiple> - multi-select, value = array[] <select multiple="checkmarks"> - multi-select, value = array[] select type="tree" may have also <select type="tree" treelines> - draw treelines <select> and <option>'s may have arbitrary markup inside (<hr>,<img>, whatever), even more any DOM element may have role="option" defined making it a selectable option : <li role="option">...</li> <option value="Sc"><code>Sc</code>Scandium</option> And as a bonus, by declaring different flows in CSS in list you may have: select { flow:horizontal; } // horizontal select select { flow:vertical-wrap; } // multicolumn select [1] https://sciter.com https://sciter.com [2] https://sciter.com/wp-content/uploads/2024/01/select-variants.png https://sciter.com/wp-content/uploads/2024/01/select-variant...
- zerocrates 3y ago
  At least some of this is hopefully on the horizon with the stylable select initiative (this was previously called "selectlist" but they seem to have pivoted to alter/enhance the select element instead): https://open-ui.org/components/selectlist/ https://open-ui.org/components/selectlist/
- cxr 3y ago
  > I do not really understand what is the problem with flexible <select> implementation in browser. There isn't a problem. Your flexibility is just in the wrong place—the flexibility is on the side of the user and user agent, e.g. to manifest and interact with a "<select multiple>" input method however best for the device that the user is looking at the form with. The fact that it's not actually codified anywhere exactly how "<select multiple>" should work is a good thing. Your approach does away with that.
zerocrates 3y ago
What's the reasoning for allowing select to have hr children but not optgroup? It doesn't seem like it would be any more problematic but I imagine I'm missing some relevant issue.
foobarbazbanana 3y ago
How turn a datetime from say mysql into a form field and back withouth js?
xp84 3y ago
Sadly, this is all academic because in all commercial work, “designers” demand that you reimplement SELECTs to make them look a very, very specific way “consistently across every OS, for our branding’s sake,” leading to devs implementing them as a soup of 42 nested DIVs, an SVG or two, and 12 event handlers, and they still don’t act right when the dropdown doesn’t have enough space below it in the viewport.

192 points by ingve 3y ago

deleted 3y ago

[deleted]

TFA mentions `optgroup` too, wouldn't it make more sense to use that and style it similarly? Especially if `hr`-in-`select` is only going to work in Safari anyway(?).

chrisb 3y ago
The article isn't completely clear; but hr-in-select is standardized [0] - and it definitely works in the Firefox v122.0 I'm browsing with. [0] https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element https://html.spec.whatwg.org/multipage/form-elements.html#th... (see the "Content model" line)
- OJFord 3y ago
  Pfft I'm an idiot - I'm reading from (and tried it out with) Firefox too!
  - genezeta 3y ago
    It's been added in 122.0 [0], but it wasn't working previously. [0] https://www.mozilla.org/en-US/firefox/122.0/releasenotes/#note-789971 https://www.mozilla.org/en-US/firefox/122.0/releasenotes/#no...
    - OJFord 3y ago
      I'm using latest FF, it did work, I said I was an idiot because despite seeing it work, trying it out in a non-Safari browser, I came here and wondered aloud if it would work other than in Safari!
- deleted 3y ago
  [deleted]
lapcat 3y ago
Optgroup has a mandatory label attribute.
vinnymac 3y ago
Not to mention the user experience for an optgroup on mobile is vastly superior as a sheet rather than a popover. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se... For those without iOS, see an example here: https://ibb.co/DkN16Gc https://ibb.co/DkN16Gc
- Pesthuf 3y ago
  <select multiple> on mobile devices is so good - why don't the finally improve the implementations on the desktop as well? The arcane 90s UI paradigm it currently uses everywhere just doesn't work. And please, just give us an attribute that adds a search bar... I don't want to use 30 KB of JavaScript just to have selects that feel like they're from this millennium, especially since those then don't work too well on mobile…
  - extra88 3y ago
    That's a text input plus a datalist. Their browser implementations also have some issues but can do the job.
    - moron4hire 3y ago
      There's a whole other ball of problem wax with input plus datalist. The options don't appear again if one has been selected already; the user first has to clear the input and then the list appears. Also, the input can't be strictly limited to the options in the datalist; the user could type in whatever they want and it's still "valid" and fulfills any required attribute added to the tag.
  - carlosjobim 3y ago
    > And please, just give us an attribute that adds a search bar... That's the datalist html element.
  - int_19h 3y ago
    What is "arcane" about the desktop multiple selection paradigm? It has been the standard way to deal with selections in all desktop OSes for decades now.
shiomiru 3y ago
Agreed, this just looks like a non-accessible <optgroup> alternative and feels like a step backwards. I fear authors will now use hr instead of properly grouping their elements, to the detriment of screen reader users. Why not just make horizontal rules between optgroups the default?

vinnymac 3y ago

> You could still see it by manipulating the DOM or using XML, but apart from a couple of experts nobody knew. Except for all the users who were frustrated by the change. Most users wouldn’t even know who to report this to, even if they noticed it at all. They may chalk up the issue to the new computer or phone they purchased in the last two decades.

lapcat 3y ago

For me the problem is that iOS already adds horizontal rules between all select options, so the new feature doesn't make any sense there, and I can't share code between Mac and iOS. I wonder if anyone on the WebKit team looked at the blog post example in Mobile Safari?

eyelidlessness 3y ago
It doesn’t render an extra separator on iOS, so you should be able to use the same markup.
- lapcat 3y ago
  I think you're missing the point. The redundancy of the <hr> on iOS means that on iOS the <hr> doesn't serve its purpose of separating the options.
  - eyelidlessness 3y ago
    I was responding to your point that you can’t share code between the platforms. It doesn’t have the same presentation, but it’s no less usable with the <hr> than without.
    - lapcat 3y ago
      > it’s no less usable with the <hr> than without. Sigh, you still don't seem to get it. The point of code is to provide functionality to the user. If I want to visually separate the options, the <hr> on iOS does not provide the functionality. Thus, I need to do something else on iOS in order to visually separate the options, and thus I can't share the <hr> code with other platforms. "no less usable" is a misleading way of phrasing the problem. The <hr> on iOS is not usable at all as a visual separator between options in a select element. It's pointless, with no use.
      - eyelidlessness 3y ago
        I’m responding from a perspective of over two decades of web development. It’s a necessary reality of the web as a platform that different rendering environments have different capabilities, and this is a fairly typical case of/for graceful degradation.

superhumanuser 3y ago

Doesn't work on Android. Every option has line below it.

neogodless 3y ago
I'm on Android and see no lines at all. (Firefox)
ahoka 3y ago
It does not work on iOS either :)

squigglydonut 3y ago

Let's get chrome support

grishka 3y ago
It does show the separators for me on Vivaldi (which is Chromium-based)
throwaway290 3y ago
It works in v120.
- kps 3y ago
  119 — https://developer.chrome.com/blog/hr-in-select/ https://developer.chrome.com/blog/hr-in-select/ is linked from the OP article, but not prominently.
squigglydonut 3y ago
Chrome android

PaulDavisThe1st 3y ago

Another fabulous example of "since we're now aiming to implement 90% of new GUIs in the browser, let's take a couple of decades to slowly add each and every element of desktop native GUI toolkits from the 1990s". Sigh.

deleted 3y ago
[deleted]
lazypenguin 3y ago
Every time I read a recommendation for webview/tauri/electron/etc. I always ask myself “what about datagrids, docking tabs, context menus, etc.?”
- deleted 3y ago
  [deleted]
akira2501 3y ago
GUI toolkits never had to be designed and implemented by committee, so they have the speed advantage. On the other hand we've got a "custom elements" implementation that's far more ergonomic and implemented across all platforms, some of them even let you play with the "internals" mechanisms, and all if it is better than I remember any GUI toolkit providing.

uses 3y ago

i had no idea <select multiple> existed. it works great on my ipad and has great browser support. https://caniuse.com/mdn-html_elements_select_multiple https://caniuse.com/mdn-html_elements_select_multiple

ErneX 3y ago
Since 1995 (HTML 2.0) https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.3 https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1....
- teddyh 3y ago
  I believe the canonical spec for HTML 2.0 is actually RFC 1866: <https://www.rfc-editor.org/rfc/rfc1866#section-8.1.3 https://www.rfc-editor.org/rfc/rfc1866#section-8.1.3>
bdcravens 3y ago
It's always been there, but for traditional browsers, it was tedious: Ctrl/Cmd + click. Many non-power users found it tricky or didn't know about it, so we all more or less settled on checkboxes as a UX standard.

alexfromapex 3y ago

Wish browsers would start shipping a sensible multi-select. There’s one now but it’s not user-friendly enough IMO.

jareklupinski 3y ago
i built one a bit ago using an event (onselect or onchange?) handler on a regular dropdown that, when you click on an item, the handler removes that element from the dropdown options, and adds it to another ul/li list under the dropdown, with a little X to reverse the process select2 does something similar but yea it's weird this isn't a built-in maybe a dropdown with checklists?
- config_yml 3y ago
  > maybe a dropdown with checklists? That's builtin with <select multiple> but it's only usable on mobile.
asddubs 3y ago
And one with drag and drop reordering. or at least some form element that allows drag and drop reordering (ideally of arbitrary markup blocks)

c-smile 3y ago

I do not really understand what is the problem with flexible <select> implementation in browser. In my Sciter[1] the following are supported ( see screenshot [2] ): <select type="dropdown"> - select with popup <select type="list"> - select list <select type="tree"> - hierarchical select (a.k.a. tree view) and all of them may have <select multiple> - multi-select, value = array[] <select multiple="checkmarks"> - multi-select, value = array[] select type="tree" may have also <select type="tree" treelines> - draw treelines <select> and <option>'s may have arbitrary markup inside (<hr>,<img>, whatever), even more any DOM element may have role="option" defined making it a selectable option : <li role="option">...</li> <option value="Sc"><code>Sc</code>Scandium</option> And as a bonus, by declaring different flows in CSS in list you may have: select { flow:horizontal; } // horizontal select select { flow:vertical-wrap; } // multicolumn select [1] https://sciter.com https://sciter.com [2] https://sciter.com/wp-content/uploads/2024/01/select-variants.png https://sciter.com/wp-content/uploads/2024/01/select-variant...

zerocrates 3y ago
At least some of this is hopefully on the horizon with the stylable select initiative (this was previously called "selectlist" but they seem to have pivoted to alter/enhance the select element instead): https://open-ui.org/components/selectlist/ https://open-ui.org/components/selectlist/
cxr 3y ago
> I do not really understand what is the problem with flexible <select> implementation in browser. There isn't a problem. Your flexibility is just in the wrong place—the flexibility is on the side of the user and user agent, e.g. to manifest and interact with a "<select multiple>" input method however best for the device that the user is looking at the form with. The fact that it's not actually codified anywhere exactly how "<select multiple>" should work is a good thing. Your approach does away with that.

zerocrates 3y ago

What's the reasoning for allowing select to have hr children but not optgroup? It doesn't seem like it would be any more problematic but I imagine I'm missing some relevant issue.

foobarbazbanana 3y ago

How turn a datetime from say mysql into a form field and back withouth js?

xp84 3y ago

Sadly, this is all academic because in all commercial work, “designers” demand that you reimplement SELECTs to make them look a very, very specific way “consistently across every OS, for our branding’s sake,” leading to devs implementing them as a soup of 42 nested DIVs, an SVG or two, and 12 event handlers, and they still don’t act right when the dropdown doesn’t have enough space below it in the viewport.