6 ms·

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> tha

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.)
        torstenvl 3y ago
        [flagged]
        crazygringo 3y ago
        > 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.
- torstenvl 3y ago
  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."
  - lapcat 3y ago
    > 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.
    - torstenvl 3y ago
      [flagged]
    - cxr 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.)
      - torstenvl 3y ago
        [flagged]
        crazygringo 3y ago
        > 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.
torstenvl 3y ago
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."
- lapcat 3y ago
  > 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.
  - torstenvl 3y ago
    [flagged]
  - cxr 3y ago