FF html5 media bug

[FunkyRes]

When using html5 media to embed an mp3 with flash player fallback, firefox does not use the fallback, but instead presents an ugly box with an X in it. I understand the patent issues, but if a fallback player object is presented and it can't handle the native media, it should use the fall back.

example:

http://www.shastaherps.org/bugs/ffmp3.html

code:

Code: Select all

<audio id="h5_vch0" controls="controls">
   <source src="/vouchers/202-1.mp3" type="audio/mpeg"></source>
   <object id="fp_vch0" width="220" height="135" data="/media/flash/flowplayer.commercial-3.1.3.swf" type="application/x-shockwave-flash">
      <param name="movie" value="/media/flash/flowplayer.commercial-3.1.3.swf">
      <param name="allowfullscreen" value="true">
      <param name="allowscriptaccess" value="always">
      <param name="flashvars" value="config={'key':'$07cb470b94495243b2c','playlist':[{'url':'/media/splash/audioVoucher.jpg'},{'url':'/vouchers/202-1.mp3','autoPlay':false}],'plugins':{'audio':{'url':'/media/flash/flowplayer.audio-3.1.2.swf'},'controls':{'height':'24','fullscreen':false}}}">
      <p>
         <a href="/vouchers/202-1.mp3">202-1.mp3</a>
      </p>
   </object>
</audio>


[FunkyRes]

btw - yes, I'm aware the end tag for source is not valid, that's a result of php's DOMDocument not knowing that it should be omitted when exporting dom object to html. It doesn't effect the bug, happens whether or not it is there (and happens in proper xhtml as well where source is self closing).

[LoudNoise]

Moving to Web Development.

[jscher2000]

This seems to be a catch-22: if a browser supports <audio> it ignores the fallback. It does not first try the src and, if it doesn't understand it, then use the fallback. That's not ideal because over time, different browsers may support different formats. However, it does seem correct:

Content may be provided inside the audio element. User agents should not show this content to the user; it is intended for older Web browsers which do not support audio, so that legacy audio plugins can be tried, or to show text to the users of these older browsers informing them of how to access the audio contents.
Source: HTML5

For now, I think you have no choice but to avoid using <audio> for unsupported formats. Perhaps HTML5 will evolve to handle this issue. Or perhaps it will lead to something like SWFObject for HTML5 media.

Misc. references:
Using audio and video in Firefox @ MDC
Media formats supported by the audio and video elements @ MDC

[FunkyRes]

But HTML 5 doesn't specify a format, so there is no way to use a format that works everywhere.

AAC and MP3 work in Safari but Ogg Vorbis only does if the user has installed software on their own.
Neither of those work in Firefox.

While in some case one can provide multiple, when you are dealing with user submitted data (such as record vouchers) that just can't be done without a lossy to lossy transcode on the server, which not only reduces quality but with most server side languages requires a system or exec call in the server side script that is often disabled because it is a security risk (I disable it on my servers).

If there is not going to be a standard media type that must be supported, then browsers need to use a fall back in the event that they do not support the specified media type.

Even a hyperlink is better than a gray box with an x in it.