<div dir="ltr">On Tue, Aug 12, 2008 at 3:46 PM, Chris Double <span dir="ltr"><<a href="mailto:chris.double@double.co.nz">chris.double@double.co.nz</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A browser that supports <video> but not Ogg will not use the fallback<br>
<object>. Instead it will just give an error when loading the foo.ogg<br>
file. <br></blockquote></div><br>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.<br>
<br>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.<br>
<br>Just some thoughts,<br>- James<br></div>