Disabling autoplay on iOS is not unreasonable. I don't want autoplay anywhere, but I really would not expect opening a web page on my phone to start blaring random audio out the speakers. I wouldn't call that "sabotage", I'd call that "someone actually cares about what users expect". (That's leaving alone data concerns, especially with limited and expensive 3G data plans.)
Theres no reason this couldn't be a user permissions thing like the geolocation API's. If the user wants a particular page to have autoplay enabled, then the user should have the choice.
How is "mute by default" different from "no autoplay" except that when users actually hit play, it would just start somewhere in the middle? (That sounds like an even worse user experience.)
It would be "no autoplay by default" instead of "mute by default".
the difference is that in the "no autoplay ever" case I would be not able to enable it if I wanted. "No autoplay by default" is the reasonable initial setting, while still giving users a choice.
I don't really call 'not supporting Ogg' sabotage. Joe Public doesn't care about Ogg. Never has, never will. How is not supporting Ogg for <audio> tags when the spec for <audio> tags doesn't require it 'sabotage'? The requirement for HTML5 to support Ogg was dropped very early on in 2007. It's not part of the standard.
Apple have been fairly supportive of WebGL: it's been in the WebKit nightly builds for almost three years now, of which Apple are a major contributor. You can accuse Apple of many things, but given how they've been part of the WebGL Working Group from its formation I'm not so sure you can say they're out to 'get' WebGL...
Joe Public didn't care about AAC and Apple Lossless either before Apple started heavily pushing them on the iTunes Music Store. Apple doesn't use popularity as its metric when determining which formats to back.
It's impossible to build an iOS game for Safari that has sound. They've limited the API by only allowing a single audio channel that can only be used during touchscreen actions. You can't programmatically play a sound, eg like when a collision occurs.
To be fair, audio support on all web browsers was an awful embarrassment, especially on mobile, until just recently. Thankfully recent versions of Chrome and Firefox are changing things, and I expect Safari (both Mac and iOS) will soon improve.
I think you're coloring Apple to be far more nefarious than they actually are. For many people, the change to only load media in response to a user's explicit action is a huge step forward, as they can confidentially browse over cellular networks without blowing out their bandwidth cap. As a user, I definitely appreciate that behavior.
And don't think I'm not affected as a developer – all the time people use our product, Hype, to create content that includes audio and video elements, and we're stuck explaining to them the behavioral differences between desktop and mobile browsers.
Apple's not evil; they're pragmatic. Right now, users needs win in this situation. Hopefully we get a more flexible solution in iOS 6.
