- From: Kit Grose <kit@iqmultimedia.com.au>
- Date: Wed, 28 Oct 2009 10:40:31 +1100
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
Received on Tuesday, 27 October 2009 16:40:31 UTC