It doesn’t render an extra separator on iOS, so you should be able to use the same markup.
For an example of how they look like in iOS 17.3 or earlier, long press the address bar/tab title in Safari
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?