[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Kit Grose]

G'day list,

I've been working on my first HTML5 frontend, which is using the video  
element, and I've run into a part of the spec that I disagree with  
(and would like to understand its justification):

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


(from 4.8.7: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html 
)

As a content producer, I have no desire to double-encode all our  
existing videos (from their current H.264 format into OGG), especially  
we really only see around 5–8% Firefox marketshare on this site. I'm  
using Kroc Camen's Video For Everybody (http://camendesign.com/code/video_for_everybody 
), so UAs which don't support the video element get a QuickTime object  
first, and a Flash 9+ player (capable of playing H.264 video) next,  
and lastly a video download link.

I expected (incorrectly, in this case) that if I only produced one  
source element (an MP4), Firefox would drop down to use the fallback  
content, as it does if I include an object element for a format not  
supported (for example, if I include a QuickTime object and QT is not  
installed, the user sees fallback content). As far as I can see, the  
only option in this situation is to rely on Javascript and the video  
element's canPlayType() function.

Can I get some sort of an understanding on why this behaviour (non- 
descript error in supported UAs rather than using the fallback content  
that can provide alternate access methods) would be preferred?

Cheers,


Kit Grose
User Experience + Tech Director
iQmultimedia

+61 (0)2 4260 7946
kit at iqmultimedia.com.au
iqmultimedia.com.au