4 ms·
Actually, the developer's primary responsibility is to deliver working software to their client or customer. If you ship a bunch of features based on an assump
by turnsout 4y ago
Actually, the developer's primary responsibility is to deliver working software to their client or customer.
If you ship a bunch of features based on an assumption about how browsers "should" implement an API in the future and it breaks, you can't tell your customers "it's the browser's fault!" Regardless of what's "fair," it's your software that looks broken. So you can navigate that however you want. I choose not to adopt single-vendor APIs for this exact reason.
- Uehreka 4y ago> you can’t tell your customers “it’s the browser’s fault!” Indeed you can’t! Which is the core of my argument for why we also need to be able to properly UA-sniff browser versions. If browsers aren’t holding up their end of the stability bargain, they need to give us a way to version-detect and handle the problem on our end. Right now what’s pissing me off about Safari is that with their left hand they’re delivering buggy implementations of standardized features and with their right hand they’re cutting off our ability to detect which version of their browser we’re running in (and soon, no doubt, whether we’re running in Safari at all).
- turnsout 4y agoI'm not unsympathetic, but I would quibble with your use of the word "standardized" here. Just because one vendor is pushing an API through the standards process does not mean it is "standardized."