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.