The State of HTML5 Audio
phoboslab.org
phoboslab.org
Mobile Safari
Can't pre-load sound files, only plays one sound at a
time, severe lag, timing issues, clicks & pops,
completely ignores every other call to play a sound,
doesn't support Ogg/Vorbis. Utterly useless for anything.
Oh, and did I mention it doesn't support Ogg/Vorbis?*
Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store.
No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading). Your blind hatred is moronic.
Further, they continue run WebKit as an OSS project, and have worked to be accommodating to other mobile providers.
The reason they dislike flash isn't some sort of inherent hatred, it's that it's outside their control. They can implement a HTML spec just as well as anyone else, and with Webkit, they can lead the way.
Apple Wants to see a strong HTML web.
They want this as long as they are not the dominant platform. If MS and Apple swapped places tonight and Apple suddenly had 90%+ marketshare, it's likely that their strategies would flip just as fast, because it's the most profitable thing to do.
Apple's interests are in ensuring that their platforms can run as much user-desired content as possible; they can do this by promoting cross-platform compatibility and interpreted code like JS and HTML.
Microsoft has no need for this, since everything runs on Microsoft by default, because if it didn't, you'd miss out on 90%+ of your potential market. Instead, Microsoft's interests are opposite; they want to do everything they can to ensure that Windows is still required for any and all meaningful usage. This is the major point of IE; do enough to mostly work, but break compatibility where you can get away with it so that developers can't forget about Windows and IE.
They also hope, though the environment isn't appropriate for this to work anymore, that IE will be your sole development platform and that considering the time it takes to make stuff work in IE, you will just leave things broken in all other browsers, further solidifying the MS lock-in.
Lock-in is the holy grail for the software vendor. Apple is putting this in place as best as they can in the markets they control, and they are trying to ensure that MS doesn't lock them out of the desktop game, because they're still vulnerable believe it or not. MS is trying to ensure that Windows' death grip remains in place FOR. EVER., just as Apple wants iPhone/iPod to do the same.
Apple is not a software vendor.
No, it is not that obvious at all. May I remind you that Apple introduced the iOS SDK, spearheads what is usually recognized as the finest rendering engine out there and built what was the first mobile device actually able to surf the web?
And that they have shown no will or wish to backtrack on any of these, doubling down instead?
There is something much, much simpler to these issues:
1. Jobs's Apple will never again live and die at the whim of a third party. They suffered greatly during the Classic-OSX transition because Apple had lost control of the development platform itself (which was basically owned by Metrowerk and its CodeWarrior)
2. Jobs's Apple takes decisions it thinks benefit its customers and its customers are always its users.
Now they may be wrong on that, and they may be misguided, but time and time again you can (pretty easily) explain the decisions of Jobs's Apple either as trying to avoid losing their platform to a third party or trying to make their user's experience life better.
With web browser they fully control the platform. Hell, they control what can be argued the best web platform available (Google's Chrome is giving them a run for their money, in no small part by building upon their work). They don't fear people using their web browser, they wouldn't have built Canvas if they did (why not leave it out as SVG? Slow, hard to use and not a threat at all), they wouldn't be implementing WebGL, they wouldn't spearheads CSS animations and transitions and all the stuff that can make web applications snazzier and cleaner, they wouldn't have the engine with the best HTML5 support by far.
Web stuff is not a threat, because they can have the best, shiniest and most advanced web stuff and they control all of it (number of full rendering engines allowed on iOS devices? one. Nobody else is allowed to ship a JS interpreter, therefore no full-blown web browser can avoid using the Webkit that ships with it and is fully built by Apple).
Apple doesn't fundamentally mind or care for cross-platform mobile apps, what they fear is a third party's cross platform toolkit taking preeminence over their own tool and deciding of their platform's future. That is why they banned flash (also, because flash is a piece of shit).
> Getting people to build with objective C and native code helps lock in
That only works because you assert Apple wants to lock users in.
> and ensures that any sales go through their payment platform.
Cross-platform tools would have the exact same restriction or face bans. iTunes payment mandate is trivially explained through integration and user-experience (did you know that Apple's subscriptions services makes user information availability to magazines opt-in by the user, whereas just about every other service makes it opt-out if opt-able at all? That's because to Apple the device owner is the customer, to just about every other publisher the magazine is the customer).
> If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention.
Either that, or I have not been wearing hate-shaped glasses.
But really, I wonder why I bother with all that typing. I should know by now that HN's view of Apple is the same as /r/tech's: a bashing wankfest.
Firefox 4 has better HTML5 support than iOS, for one.
You must not have much experience in computing. Pretty much every [1] platform provider seeks lock-in. Google seeks it just as much as everyone else, their primary platform just happens to be their web services and not a specific OS. Microsoft and Symbian and RIM do as well, of course, and presumably HP/Palm would as well if they had any customers.
http://en.wikipedia.org/wiki/Vendor_lock-in#Apple_Inc.
[1] Save for, perhaps, a few co-dependent open source platforms.
For example, Webkit is the rendering engine with the worst CSS 2.1 support of the big 4, last I checked, based on the results of the CSS 2.1 test suite. Yes, it claims to implement all of it, but the quality of the implementation is not as good as the others.
For another example, Webkit is the only rendering engine I know that claims to implement CSS3 Selectors but purposefully does so incorrectly because they think doing it right would be "too slow".
This is one thing IE8/9 have actually been doing right. When they commit to implementing a feature they've been implementing it well. The feature set is smaller than webkit, but there are fewer gotchas in the features they do support...
The Audio API's .play() method is now always disabled. It was working on the iPad iOS 4.1 only through a hack, but Apple closed that hole in 4.2. I have no hatred of Apple, I own plenty of Apple products, but absurd strategic crippling of standards does not help my impression of them. It just wreaks of Microsoft-style embrace, extend, extinguish.
Well… yeah, when would you want to enable it in order for the user to always have control over the sound?
"I've heard some arguments that it is crippled on purpose, because you don't want a website to start blaring music at you as soon as you open it. Fine, I understand that argument. But why not ask the user for permission to play audio and then do it right? It's already been done with Geo Location and Storage."
Even if that's true, I, for one, despise the idea of any kind of audio autoplay for the web, be that flash or html5. If that breaks web games -- tough luck.
I might be OK with some kind of whitelist, though -- same way it works e.g. for large off-line storage. But I like my games and audio editing software native anyway, thankyouverymuch.
It's worse than that, it breaks the standard. Audio API can no longer be used reliably if a major portion of the audience can't utilize it. Remember when days when one major heavyweight would refuse to follow standardized web protocols? You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. Stuff like that needs to stop.
And XHTML too.
Flash might have a lot of bad points (which I'd be the first to call out) but RTMP audio (which also handles both video and arbitrary data) really isn't its worst feature, and for this reason alone its going to be a significant part of the internet for many years to come.
http://chromium.googlecode.com/svn/trunk/samples/audio/index...
edit: The in-progress spec - http://chromium.googlecode.com/svn/trunk/samples/audio/speci...
I can relate to this feeling.
My experience is entirely aligned. I was trying to use <audio> earlier this week for an incredibly simple task (occasionally play a 0.5s notification sound).
The only thing that worked reliably was Chrome (9) with a data: URI. FF3.6 (or Chrome with a normal URI) would only play the sound once, and Safari wouldn't play it at all. (These are all the Mac versions, and I didn't test Opera).
I really wanted speex encoded audio but that is not an option. If I remember correctly Opera handled streaming speex/ogg like a champ. Firefox may have worked... I can't remember. Everything else sucked.
Regardless, he's definitely made his point well (and my setup showing different but similarly bad results from his only proves his point): support for the <audio> tag is not really as solved as browser manufacturers are claiming, and is not currently a suitable competitor to Flash.
Direct link to test: http://www.phoboslab.org/files/html5audio/
I know you know this, but for everyone else, Firefox doesn't play chained ogg files. Icecast uses this feature. If the icecast stream doesn't use chaining then it plays.
[1] http://chromium.googlecode.com/svn/trunk/samples/audio/index...
[2] http://audiotool.com/app [SWF]
2) It doesn't solve the iOS problem (which, as this post points out, has even more issues than desktop browsers)