Hacker News Reader

Comment by st3fan | Hacker News Reader

How have they sabotaged HTML Audio?

The biggest problem is definitely not the lack of OGG support but the disabling of autoplay on iOS: http://weblogs.vpro.nl/digitaal/2011/11/04/why-html5-audiovi...

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.)

They could always allow you to mute sites by default. You see to be overly optimistic that they are doing it for the users good.

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.

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.

Settings -> Safari -> Audio -> On/Off, or with a permissions dialog

There is no good reason to have Audio off by default and have no way to turn it on for games.

By not supporting Ogg Vorbis on Desktop and totally fucking it up on Mobile on purpose:

http://www.phoboslab.org/log/2011/03/the-state-of-html5-audi... (Year old, but still valid)

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.

> Joe Public doesn't care about Ogg

But developers care, a lot. You have no idea how many popular games use Ogg internally.

Here's a small list: http://wiki.xiph.org/index.php/Games_that_use_Vorbis

Looking at the games, I wouldn't be surprised if a billion copies have been sold to date.

Do you know why games use Ogg internally? Is it just licensing or does Ogg have some technical advantage for them?

Audio cannot be played automatically -only when a user event occurs.

Audio cannot be streamed playlist-style, one after the other - again, it always requires user input.

So this screws things up completely for html5-based games with audio.

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.

Hell, it's not like Android is a shining example of audio support: http://code.google.com/p/android/issues/detail?id=9372

No, HTML5 audio actually kind of worked in iOS 3. But Apple plugged that whole and made sure it was fully sabotaged in iOS 4.

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.

Reply on news.ycombinator.com