UPDATE: Here’s a new post about a cross-browser HTML5 audio player with Flash fallback that effectively solves the problem described below.
In a previous post, I mentioned that I wanted to see first-hand how each browser renders default controls for the HTML5 audio element. I created a simple demo page and tested it in the following browsers:
- Firefox 4 – Mac (OSX 10.6)
- Safari 5 – Mac (OSX 10.6)
- Chrome 10 – Mac (OSX 10.6)
- Internet Explorer 9 – PC (Vista)
- Firefox 4 – T-Mobile G2 (Android 2.2)
- Opera Mobile 11 – T-Mobile G2 (Android 2.2)
- Default Browser – T-Mobile G2 (Android 2.2)
- Safari – iPad and iPod Touch (iOS)
As I tested the demo on the G2 in Android 2.2′s (aka Froyo) default browser I was surprised to see that I get neither the browser’s default controls nor the fallback message enclosed inside the audio element. How could this be?
It’s my understanding that any text between the opening and closing audio tags will be displayed in browsers that do not support the audio element. So if that text doesn’t appear in then the browser supports HTML5 audio, right? So why does Android 2.2′s browser display the following:
In every other browser tested, the following code rendered either audio controls or the fallback text:
Your browser does not support HTML5 audio.
Logically, this tells me Android 2.2′s browser doesn’t support mp3 or ogg media types which is odd given the fact that every other tested browser supports one of the two codecs. So if Android’s browser doesn’t support these codecs, which does it support? Again, I created a test page to help me answer this question. (Click here to see which audio codecs your browser supports.)
If you view the source on the test page you’ll see that first I check whether the browser can create an instance of the audio tag and whether it has the canPlayType method. If that test succeeds, I then test the most widely used codecs to see if they are supported in this particular browser. Calling canPlayType for a particular codec returns either “probably”, “maybe” or empty. Empty means that the codec isn’t supported. When I visit this test page on my Android device I see the following:
As you can see, technically Android 2.2′s default browser supports HTML5 audio (in the sense that programmatically-created element has the canPlayType method) but it can’t play any media files encoded with popular codecs. So as it turns out in the case of the native Android 2.2 browser, you can’t simply let the browser interpret the markup to make the determination as to whether it can play audio. Though Google will likely fix this in future versions of Android, it will be up to the various service providers as to when this update is distributed to users. So it’s likely that this will continue to be an issue for awhile. This is definitely something to consider when providing fallback content for HTML5 audio.