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 :
> 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.
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):
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
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(?).
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!
<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…
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.
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.
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.
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?
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.
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
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.
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.
> I’m not interested in whatever needlessly aggressive and pointless argument you’re trying to have. Cheers!
It's unfortunate when people in the wrong decide they'd rather stop the conversation rather than learn from it. And it's even worse when they're insulting about it ("aggressive", "pointless").
Your original comment was:
> but it’s no less usable with the <hr> than without
And the fact is that it is less usable. The <hr> provides a grouping that improves usability. On iOS, that grouping is not there. It's not merely a matter of aesthetic "presentation", it's eliminating information that may be crucial to understanding the presented options. Just because all the options are still there to click doesn't mean usability hasn't been impaired.
Companies run usability studies all the time on their software -- when all the software functionality is already there -- to figure out where the interface is still unclear or confusing, i.e. less usable.
(Or to look at it from a second angle: it's semantic information in the HTML being ignored. It's not merely presentation information residing in the CSS that can be considered optional.)
> Please don't edit, trim, or cut off others' quotes so that you can misrepresent their position.
I didn't misrepresent anything.
I don't understand your comment at all. That's literally what I quoted -- "but it’s no less usable with the <hr> than without". I quoted what you say is the correct quote. And it's false, for the reasons I gave.
If you're designing expecting the <hr> to be supported ("with the <hr>"), and it isn't supported, usability degrades (i.e. becomes "less usable"). They made the point that it's graceful degradation, and my point is confirming that whether it's "graceful" or not, it still degrades usability which is all that matters. It's still a negative.
> so why you bristled like that is a bit perplexing
Just because somebody disagrees with you, that doesn't mean they're "bristling". It's not only insulting to say that, but it's also just plain wrong. And it's not helping the conversation.
If you truly didn't intend to misrepresent it, then you must have misunderstood it. That's difficult for me to imagine because it's quite straightforward, but perhaps you aren't a native speaker, or are undercaffeinated.
He didn't say it was no less usable if "it isn't supported." He said, assuming it isn't supported, it is no less usable than not including the <hr>
Put another way, HE is comparing usability on iOS of
Those are different comparisons. Discussing iOS, he said "it’s no less usable with the <hr> than without." You made it seem like he said "it’s no less usable without support for <hr> than with support." That isn't what he said.
Because <hr> in <select> is not supported on iOS, it is ignored. The resulting browser behavior is identical. It is impossible for one to be less usable than the other because the result is utterly down-to-the-pixel indistinguishable.
As a result, eyelidlessness rightfully pointed out that lapcat was incorrect when he said "I can't share code between Mac and iOS." While the iOS experience would not be as good as the Mac experience, the iOS experience with the <hr> would be no less usable than the iOS experience would be without it.
My understanding of his comment is indeed what you've now correctly described as my understanding of it.
The different understanding you have would be a meaningless comment because it would just be a tautology. In me eyes, that wasn't the conversation being had, not on either side. Upon re-reading it, I continue to think that.
For posterity in case you’re interested, torstenvl‘s understanding of what I said is correct. The tautology—that something with no effect has no negative effect—is important in understanding how to address inconsistencies between browser environments.
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?
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?
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".
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.
In my Sciter[1] the following are supported ( see screenshot [2] ):
and all of them may have select type="tree" may have also <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 : And as a bonus, by declaring different flows in CSS in list you may have: [1] https://sciter.com [2] https://sciter.com/wp-content/uploads/2024/01/select-variant...