Note: if a browser returns “no” for .canPlayType(), it’s an old implementation. The spec currently requires the empty string for “I know I can’t play this” (because the empty string is == false, so testing for the value is easy).

The other two values, “maybe” and “probably”, are indeed pretty weird, but they’re a direct result of the weirdness surrounding audio formats and containers. To put it simply, it’s nearly impossible to tell if you can actually play a given file without just passing it to your decoder and seeing if it throws an error.

So, at best browsers can offer a “probably” for when they’re pretty sure a particular file is playable. “maybe” is for the even more uncertain cases, like when you specify the type as a container format without giving the codec. The browser may support decoding the container, but without more knowledge it can’t give you an answer as to whether the file itself is playable.

So, yeah, it’s kinda weird, but it’s a good compromise with reality. Just remember that the “I know I can’t play it” case can just be treated like it returned false, as long as you’re not using ===. Something easy like “if( (new Audio()).canPlayType(type) ) {…}” will work fine.

The reason audio and video tags were not implemented in early html/etc (in my guess) is because it wasn’t realistic to even consider under the dial-up bandwidth of the time. Audio and video files take a lot of bandwidth, of course.

I remember when downloading a 5meg file took anywhere from 15 to 45 minutes, depending on network conditions.

YouTube would not even function on dial-up. It was the dark ages, for sure. ;)

Thanks, all, for the comments.

David: I believe HTML5 audio is in the “Gingerbread” (Android 2.3) release. Re: Test pages, it might not be a bad idea to put together a table of common canPlayType() sort of calls.

Tab: Good point re: canPlayType() and “no” responses; in testing I saw a mix of “no” and “”. The latter is smart, given it makes for a nice truthy/falsy test – even if the API is still goofy, it reflects the complicated situation of mixing containers, support and formats. In SoundManager 2, I look for a “probably” response as an indicator of support for a given format; I also specify codecs in the test and try a few variants to coax a best-case response out of the given browser. Despite best efforts, some browsers won’t say “probably” at this time.

Of course, if developers simply drop <audio> elements and use multiple <source> tags, most of this becomes moot as the browser handles it all – but the dynamic, JavaScript application land is what I’m most interested in, and is where things get pretty funky. It’ll be interesting to see how things evolve.

Patrick: You are correct that HTML does not mandate a standard image format, but it was a different (i.e., research-oriented) environment back when browsers were implementing image support vs. today’s business/commercial web world, of course.

GIFs still work in browsers despite some copyright assertions, and we still have the IE 6 PNG problem, but that browser is finally – wait for it – fading, itself. ;) (zing! / groan / boo, hiss, etc.)

I forgot to mention, I’m on the twitters over at @schill and try to share interesting and nifty things I find about JS, audio, CSS and so on.

“With img, you typically don’t have to worry about format support – it just works – and that’s part of what makes a standard wonderful. JPEG, PNG, BMP, GIF, even TIFF images all render just fine”

note though that HTML never actually defined any formats that browsers should support. which image formats browsers actually support can also still vary (thinking PNG24 and IE for instance). and who can forget the patent war around GIF?

yes, NOW the situation is fairly stable, but it’s not always been this way. same thing with audio/video formats/codecs

Love the title of this post! While I understand we can’t really expect a boolean response (true/false), the return values of “probably”, “maybe”, and “no” are downright laughable. Truly a glass is half empty API. ;)

Thanks for sharing your experience about audio tag. While the video tag has been largely tested, it’s the first I read about audio… I keep it in mind for future development.