- From: James Ide <ide@berkeley.edu>
- Date: Tue, 12 Aug 2008 16:42:48 -0700
On Tue, Aug 12, 2008 at 3:46 PM, Chris Double <chris.double at double.co.nz>wrote: > A browser that supports <video> but not Ogg will not use the fallback > <object>. Instead it will just give an error when loading the foo.ogg > file. > In this case I believe it would be possible to listen to the `error' event and dynamically insert fallback content if the <video> element has an error state of MEDIA_ERR_DECODE. However, this fails when using <source> elements as the resource-selecting algorithm just terminates if all of the media sources are of unsupported types. More complications arise when we consider cases where only a subset of the codecs in the resource are supported and different events are fired and error codes set. I agree that there should be some type of fallback mechanism in place, perhaps akin to how <object> deals with unsupported data. Currently <source> fills in some of the gaps by providing fallback support to a degree, but I feel that there should be a more comprehensive solution that encourages authors to use <video>, with or without <source>, but also provides a safety net by allowing currently existing fallback solutions to function as expected. Intuitively, I would expect <video> with an unsupported codec to behave as if the <video> element itself were unsupported, with perhaps a small note on how to acquire the codec(s) required to play the media, if the UA can determine that much and is configured to display such messages. Just some thoughts, - James -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080812/84977621/attachment.htm>
Received on Tuesday, 12 August 2008 16:42:48 UTC