Feature detection is usually the way to go. If your website / webapp depends on a particular feature, check if that specific feature exists, rather than checking for particular browsers. Browser checks are still needed in some cases, for example Safari sometimes reports that it supports particular features but it really doesn’t (or they’re so buggy to the point where they’re unusable), but that’s relatively rare.
This is tough to implement when the feature is present, but implemented wrong. Or, even worse, when it’s implemented right, but the most popular browser implements it wrong and almost everyone else follow suit for compatibility reasons, except for one that takes the stance of following standards. I know safari is notorious for this, think pale moon had those issues, too, and there are still echoes from the past from pre-chrome internet explorer, thank god it’s finally dead.
At least Chrome is mostly standards-compliant and doesn’t do anything too weirdly. I’d say Safari is the new IE - lots of weird bugs that no other browser has, and sometimes you need hacks specific to Safari.
That’s fair. I meant that more in terms of using market dominance to shape the browser market, and not in entirely good ways.
I’ll rue the day that every website insists it only works with Chrome because of some user-privacy degrading feature that Google insists is a core web technology.
I couldn’t say that it is. Chrome team’s usual approach is to make and release stuff first, write specifications later. By the time the other browsers come along, there’s already both market adoption and bunch of dumb decisions set in stone as a standard. Most notable examples of this would be QUIC and WebUSB
This is tough to implement when the feature is present, but implemented wrong
Sometimes it’s doable if you can call the API and check that the result is what you’d expect. For example, a long time ago some browsers incorrectly handled particular Unicode characters in JSON.parse. Sites could check for the incorrect behaviour and shim JSON.parse with a version that fixes the output.
I’ve never worked with WebRTC but I imagine it might be difficult to do that with some of its APIs given they require camera or microphone access (meaning you can’t check for the bug until the user actually tries to use it).
This is tough to implement when the feature is present, but implemented wrong. Or, even worse, when it’s implemented right, but the most popular browser implements it wrong and almost everyone else follow suit for compatibility reasons, except for one that takes the stance of following standards. I know safari is notorious for this, think pale moon had those issues, too, and there are still echoes from the past from pre-chrome internet explorer, thank god it’s finally dead.
Chrome is the new Internet Explorer.
At least Chrome is mostly standards-compliant and doesn’t do anything too weirdly. I’d say Safari is the new IE - lots of weird bugs that no other browser has, and sometimes you need hacks specific to Safari.
That’s fair. I meant that more in terms of using market dominance to shape the browser market, and not in entirely good ways.
I’ll rue the day that every website insists it only works with Chrome because of some user-privacy degrading feature that Google insists is a core web technology.
I couldn’t say that it is. Chrome team’s usual approach is to make and release stuff first, write specifications later. By the time the other browsers come along, there’s already both market adoption and bunch of dumb decisions set in stone as a standard. Most notable examples of this would be QUIC and WebUSB
Sometimes it’s doable if you can call the API and check that the result is what you’d expect. For example, a long time ago some browsers incorrectly handled particular Unicode characters in JSON.parse. Sites could check for the incorrect behaviour and shim JSON.parse with a version that fixes the output.
I’ve never worked with WebRTC but I imagine it might be difficult to do that with some of its APIs given they require camera or microphone access (meaning you can’t check for the bug until the user actually tries to use it).