• MudMan@fedia.io
    link
    fedilink
    arrow-up
    2
    arrow-down
    5
    ·
    24 hours ago

    You are right, I keep doing that.

    Bugs and security problems aren’t bad UX, they’re a backlog.

    You may not be able to afford the implementation, but that’s not the same as arguing the feature has no value. You want to argue that case insensitivity would be better but it’s too hard/problematic to implement? I can have that conversation.

    Arguing that it’s the better option in general? Nah, lost me there.

    Sorry, I said last word and then came back, but I feel we’re closer to meeting in the middle now, so maybe worth it. All yours again. This time I’m gone for reals.

    • masterspace@lemmy.ca
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      edit-2
      22 hours ago

      Bugs and security problems aren’t bad UX, they’re a backlog.

      No, they’re not. If you are building a platform for developers to build apps on and you design your API in a way that’s easy to introduce security vulnerabilities that’s not a backlog, that’s a badly designed platform that will be riddled with insecure apps creating a crappy, untrustworthy, ecosystem. And since those bugs are in third party apps you have no control over whether app developers are aware of them or if they’ll ever get to them in their backlog.

      Again, this is literally the same thing as the JavaScript equality comparator.

      It’s not a bad idea for a user facing UX in some cases, but it’s not good for all cases and thus shouldn’t be implemented at the low file system level.