Bringing Back Horizontal Rules in HTML Select Elements | Hacker News Reader

Bringing Back Horizontal Rules in HTML Select Elements

webkit.org

192 pointsingve68 comments

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 [2] https://sciter.com/wp-content/uploads/2024/01/select-variant...

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/

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

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

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?

> maybe a dropdown with checklists?

That's builtin with <select multiple> but it's only usable on mobile.

And one with drag and drop reordering. or at least some form element that allows drag and drop reordering (ideally of arbitrary markup blocks)

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(?).

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#th... (see the "Content model" line)

Pfft I'm an idiot - I'm reading from (and tried it out with) Firefox too!

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/#no...

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!

Optgroup has a mandatory label attribute.

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/se...

For those without iOS, see an example here: https://ibb.co/DkN16Gc

<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…

That's a text input plus a datalist. Their browser implementations also have some issues but can do the job.

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.

> And please, just give us an attribute that adds a search bar...

That's the datalist html element.

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.

See bdcravens's response: <https://news.ycombinator.com/item?id=39158003>

(Note though that you aren't limited to Ctrl-clicking. There's Shift-clicking, too, as well as mouse lassoing. Assuming your UA supports it, that is.)

Funny, it looks way better on mobile than it does on desktop [1].

On desktop (Chrome on Mac) each optgroup label is just a disabled item, and then its options are indented menu items below it.

It looks totally hacky -- the name of a group shouldn't seem like "disabled" option, nor are indentations in menu items an established convention.

That sheet on iOS is perfectly intuitive, however.

[1] Link to page section with demo: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...

Firefox renders group titles using bold italic font while indenting the items under it, so it looks like a header.

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?

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.

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

Since 1995 (HTML 2.0)

https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1....

I believe the canonical spec for HTML 2.0 is actually RFC 1866: <https://www.rfc-editor.org/rfc/rfc1866#section-8.1.3>

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.

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.

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

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?

It doesn’t render an extra separator on iOS, so you should be able to use the same markup.

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.

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.

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

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.

> I’m responding from a perspective of over two decades of web development

How is that relevant to my point?

> this is a fairly typical case of/for graceful degradation.

I'm not interested in "degradation". I'm interested in my code actually working as intended and serving a useful purpose. It's great that the <hr> on iOS degrades gracefully, but that still doesn't help me even one tiny bit.

The use of serving <hr>-in-<select> to iOS is to avoid having to maintain two different code bases, which is an anticipated problem you specifically complained about, saying "I can't share code between Mac and iOS."

Choosing to serve different code to different browsers complicates development and maintenance, for almost no upside (minuscule bandwidth savings).

Serving the same code, including serving <hr>-in-<select> to iOS, has the significant benefit of simplifying development and maintenance, has the benefit of automatically "upgrading" iOS users to your better experience once their browser supports it, and has no negative impact on usability (the iOS <select> looks and behaves identically with or without the <hr>).

That is the point eyelidlessness is trying to make. There are two courses of action, one of which has a lot of downside and little upside, the other has a fair amount of upside and no downside. That's what he meant when he pointed out that "it’s no less usable with the <hr> than without."

> Choosing to serve different code to different browsers complicates development and maintenance,

I didn't say I was going to serve different code to different browsers. I said I would have to serve different code to different browsers if I used <hr> in <select>. That's a hypothetical. The alternative is actually to use a totally different technique for separating options that works on both desktop and mobile.

> for almost no upside (minuscule bandwidth savings).

It's not about bandwith! It's 100% about the user interface. That's what neither you nor eyelidlessness seems to understand. The entire point of using <hr> in <select>, or some other technique for separating options, is for the user interface.

> no negative impact on usability (the iOS <select> looks and behaves identically with or without the <hr>).

What you describe is a usability problem. That's a bug, not a feature.

It really boggles my mind that you can't understand the basic requirement: I want to separate the options on both Mac and iOS. Leaving the options unseparated on iOS is not an acceptable alternative.

It sounds like when you say "requirement" and that you "can't share code" and the result would be "unacceptable", you mean something else. Something like, "I just don't want it like this (even though there's not actually any hard and practical requirement here that it does the thing I want)".

> even though there's not actually any hard and practical requirement here that it does the thing I want

The practical requirement is the user interface.

The entire purpose of the <hr> in <select> is to visually separate the options for the user. If the visual separator only appears for some users but not for other users, that's a failure of the user interface.

Imagine if it wasn't Mac vs. iOS users but rather that there was a WebKit bug where the <hr> only appeared 50% of the time, randomly, for Mac users. Wouldn't you consider that to be a problem?

Yes—a bug, even. Still doesn't change the meaning of "requirement".

It feels like you just deliberately want to misunderstand me. What exactly do you think "requirement" means, and where do you think requirements come from? Only from God? Only from laws of nature?

There is no misunderstanding. You're not talking about a requirement.

iOS popup menus have actual separators, they are much thicker than those lines around each item. They just haven't shipped hr for select support in Safari for iOS yet (they will in 17.4, you can try it in the beta)

For an example of how they look like in iOS 17.3 or earlier, long press the address bar/tab title in Safari

For those without an iOS device see this example: https://ibb.co/N7Mw4dW

Are you under the mistaken impression that this feature is already implemented in mobile Safari on iOS 17.3? It isn’t.

On iOS 17.4, you’ll be able to see that the divider is thicker and obvious. Long-press on the Safari address bar for an illustrative example. See the gap between “Voice Search” and “Move to Tab Group”?

> Are you under the mistaken impression that this feature is already implemented in mobile Safari on iOS 17.3?

The blog post didn't mention iOS at all. I'm glad to hear that the feature is coming in the future, though it's strange that the blog post didn't mention it, and also strange that they didn't implement it in 17.0 at the same time as desktop.

> The blog post didn't mention iOS at all.

Probably because iOS 17.4 is in beta and just got released a few days ago.

The blog post was actually published on the same day and a little after the iOS 17.4 beta was released.

This is a very odd coincidence, since the Mac change was released way back in September with version 17.0, which the blog post does mention.

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

I'm on Android and see no lines at all.

(Firefox)

It does not work on iOS either :)

Let's get chrome support

It does show the separators for me on Vivaldi (which is Chromium-based)

It works in v120.

119 — https://developer.chrome.com/blog/hr-in-select/ is linked from the OP article, but not prominently.

Chrome android

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.

Every time I read a recommendation for webview/tauri/electron/etc. I always ask myself “what about datagrids, docking tabs, context menus, etc.?”

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.

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

Reply on news.ycombinator.com