OK, but you see how you’re saying “there is no standard implementation, so the solution is not having the feature, as opposed to selecting a standard”.
That’s wrong. It’s just bad implementation. Or, rather, it’s bad prioritization of UX, which is then bad implementation by default.
Also, having case sensitivity be a user toggle is not the same as having no case insensitivity. We know case sensitivity works technically, you need to do additional work to make certain characters be read as equivalent. I don’t mind if grandma wants to set her documents folder to be case sensitive to hack the world. I mind that there is no feature to make it so she can’t be confused about what file she’s selecting because the engineers didn’t like having to deal with edge cases.
Alright, I’m getting trauma flashbacks now. I think we’ve established our positions. Happy to give you the last word.
You keep thinking you’re prioritizing UX, while ignoring and talking past the mountain of bugs and security problems this causes, as if those aren’t catastrophic UX problems.
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.
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.
OK, but you see how you’re saying “there is no standard implementation, so the solution is not having the feature, as opposed to selecting a standard”.
That’s wrong. It’s just bad implementation. Or, rather, it’s bad prioritization of UX, which is then bad implementation by default.
Also, having case sensitivity be a user toggle is not the same as having no case insensitivity. We know case sensitivity works technically, you need to do additional work to make certain characters be read as equivalent. I don’t mind if grandma wants to set her documents folder to be case sensitive to hack the world. I mind that there is no feature to make it so she can’t be confused about what file she’s selecting because the engineers didn’t like having to deal with edge cases.
Alright, I’m getting trauma flashbacks now. I think we’ve established our positions. Happy to give you the last word.
You keep thinking you’re prioritizing UX, while ignoring and talking past the mountain of bugs and security problems this causes, as if those aren’t catastrophic UX problems.
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.
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.