Even if apps using Web Audio didn't do user-agent detection, many of them would need to be updated anyway because Web Audio (as it shipped in Chrome, at least) is a steaming pile. It's incredibly poorly specified in areas that matter when it comes to compatibility - for example:
You can't reliably detect the audio formats Web Audio can decode, and they vary both across hardware and software configurations (because the spec doesn't specify them), so your only choice is to download an entire audio file, try to decode it, and if you fail, download another and try that. Worse still, the <audio> mechanism of handing the browser a list of sources (so it can try to aggressively reduce wasted bandwidth) doesn't work because Web Audio requires you to download a full file before it can be decoded. Oops!
Shipped demos out there rely on Chrome-only Web Audio features that never made it into the spec, because Web Audio was written first as a non-portable implementation and then haphazardly turned into a spec while people were already building code against that implementation.
The spec changed after Google shipped it to the public (without putting it behind a flag or otherwise versioning it) so there are corner cases (albeit mostly small ones) where two spec-compliant implementations (Firefox and Chrome's for example) will produce different output. The only way to address some of these is update the application.
On the bright side, devs from both Mozilla and Google (among others) are working hard on addressing the issues, so it'll probably be fine in a year or so.
No, but that thread is golden, and certainly captures the essence of the agent-sniffer. That is, if YHWH had ever heard of agent sniffing, he would do it all the time and complain bitterly whenever it breaks, which is also all the time. Like any skilled troll, YHWH kept me guessing as to whether he was actually trolling or not. Those mozilla folks have the patience of ages. Best response was:
For future reference: look into externalizing your scripts/css into a separate file and referencing that instead of copying and pasting to every page.
I also liked the find | xargs and sed one-liners. They might as well have been speaking Aramaic.
My favorite bug report. The reporter of the bug runs quite a few over the top early 2000s looking religious websites. I won't post them here because they give me a ton of security warnings on FF but the more adventurous reader may want to take a look. Lack of -moz-opacity:0.7 should really be at the bottom of the reporters problems.
Entitlement and true idiocy. It was so entertaining to read because the author is moaning and bitching about using an experimental feature. Great candidate for being an IE6 advocate.
The developers are pretty unsympathetic though. That disclaimer on the third paragraph of CSS_Reference/Mozilla_Extensions? It might as well have been on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. I understand the reasoning for removing the prefixed version, but they should at least give the developers more warning!
Ugh, why do people do that to begin with? :( I've had Web Audio for a while since I'm on the Aurora channel, and there's so many demos that refuse to work for no reason.
I try to do my part by submitting pull requests that fix it, when possible, but most of those pull requests have been sitting ignored for months.
Clearly more people need to be educated that user-agent sniffing = bad.
Sorry, you're wrong. I hate to be rude about it, but I'm really getting tired of people, who don't know any better, acting like feature detection is always the way to go.
Feature detection simply doesn't work it many cases, and there's no alternative. Especially with new stuff like audio, sometimes function calls need to be called in different orders, have subtly different behaviors, etc., and user-agent sniffing is literally the only thing you can do.
When I programmed an HTML5 music player, calling .load() before .play() on one platform was necessary, and on another it would crash the Android browser IIRC. No choice but to use user-agent sniffing -- I probably had 20 different things that depended not just on the browser, but on the browser version.
I'd love if we could use just feature detection. Unfortunately, we have to program in the real world.
I agree in principle. But I've got to get stuff done in the real world. I don't have an extra week to read the 22,554 words of JUST the video/audio spec in HTML5, and try to figure out not just how all the browser versions differ from each other, but also how they differ from the spec:
Sometimes user-agent sniffing is the only remotely sane thing you can do. Blame the browsers, not the programmers who have to work around their "idiosyncracies".
I'm cheerfully assuming that you're using distilled documentation and not the literal spec. If there is, say, conflicting documentation from Mozilla and Google, then we certainly have a bigger problem.
You would assume rightly, of course. Unfortunately, Mozilla documentation, which is the best around, is sorely lacking on the details of the HTML5 audio implementation, like proper usage of the load() method, and when it's supposed to be called or not called and when. [1] And I don't really know what Google documentation you're talking about.
So that's the whole point. People who go on about "feature detection" and "follow the spec", and think it's that simple, really don't seem to understand what's actually going on.
You can't reliably detect the audio formats Web Audio can decode, and they vary both across hardware and software configurations (because the spec doesn't specify them), so your only choice is to download an entire audio file, try to decode it, and if you fail, download another and try that. Worse still, the <audio> mechanism of handing the browser a list of sources (so it can try to aggressively reduce wasted bandwidth) doesn't work because Web Audio requires you to download a full file before it can be decoded. Oops!
Shipped demos out there rely on Chrome-only Web Audio features that never made it into the spec, because Web Audio was written first as a non-portable implementation and then haphazardly turned into a spec while people were already building code against that implementation.
The spec changed after Google shipped it to the public (without putting it behind a flag or otherwise versioning it) so there are corner cases (albeit mostly small ones) where two spec-compliant implementations (Firefox and Chrome's for example) will produce different output. The only way to address some of these is update the application.
On the bright side, devs from both Mozilla and Google (among others) are working hard on addressing the issues, so it'll probably be fine in a year or so.