I wonder if anyone on the WebKit team looked at the blog post example in Mobile Safari?
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”?
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.
Probably because iOS 17.4 is in beta and just got released a few days ago.
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.
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.
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.
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."
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.
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?
For an example of how they look like in iOS 17.3 or earlier, long press the address bar/tab title in Safari