3 ms·

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

by lapcat 3y ago

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?

eyelidlessness 3y ago
It doesn’t render an extra separator on iOS, so you should be able to use the same markup.
- lapcat 3y ago
  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.
  - eyelidlessness 3y ago
    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.
    - lapcat 3y ago
      > 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.
      - eyelidlessness 3y ago
        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.
        lapcat 3y ago
        > 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.
        eyelidlessness 3y ago
        [flagged]
        crazygringo 3y ago
        > 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.)
  - TheCoreh 3y ago
    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
vinnymac 3y ago
For those without an iOS device see this example: https://ibb.co/N7Mw4dW https://ibb.co/N7Mw4dW
chrisoverzero 3y ago
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”?
- lapcat 3y ago
  > 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.
  - alwillis 3y ago
    > 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.
    - lapcat 3y 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.

by lapcat 3y ago

eyelidlessness 3y ago

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

lapcat 3y ago
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.
- eyelidlessness 3y ago
  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.
  - lapcat 3y ago
    > 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.
    - eyelidlessness 3y ago
      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.
      - lapcat 3y ago
        > 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.
        eyelidlessness 3y ago
        [flagged]
        crazygringo 3y ago
        > 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.)
- TheCoreh 3y ago
  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

vinnymac 3y ago

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

chrisoverzero 3y ago

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”?

lapcat 3y ago
> 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.
- alwillis 3y ago
  > 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.
  - lapcat 3y 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.