On Tue, Aug 12, 2008 at 3:46 PM, Chris Double <[EMAIL PROTECTED]>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