That makes some sense. So the UA would handle missing codec problems like many handle missing plug-ins. Is that part of the spec already? From what I have gathered, it seemed that everyone was/is content with the UA just displaying nothing when the video couldn't be rendered even if it did support the <video> element.<br>
<br>For me, I was personally planning on putting the <embed> element instead of text. So it would be (like my very first example), <video src=""><embed /></video>.<br><br>The plan here was to make the video available to the new iPhone 3.0 OS which supports the <video> element, and then the flash version of the same video would be available to those who had Flash installed but was using an older UA.<br>
<br>But the concern was "what happens when a UA _does_ support the <video> element and cannot render the resource?"<br><br>And the proposed answer in the spec was: "User agents that cannot render the video may instead make the element represent a link to an external video playback utility or to the video data itself."<br>
<br>My proposal is that it is changed to "User agents that cannot render the video should instead make the element represent a link to an external video playback utility, offer instructions or steps to install the appropriate codec, or offer a link video data itself."<br>
<br>I might even want to use "must"<br><br>Cheers<br><br><div class="gmail_quote">On Wed, Mar 18, 2009 at 9:15 AM, Simon Pieters <span dir="ltr"><<a href="mailto:simonp@opera.com">simonp@opera.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Wed, 18 Mar 2009 17:08:27 +0100, Nathanael Ritz <<a href="mailto:nathanritz@gmail.com" target="_blank">nathanritz@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For the same sort of reason we would want "to show text to the [users of<br>
older browsers] informing them of how to access the video contents." I don't<br>
think the problem of being unable to access the video contents is going to<br>
be purely for those with older browsers.<br>
<br>
Instructions on how to find the appropriate codec is an example of the kind<br>
of information a user with a newer browser might like to know when a video<br>
can't be rendered. And that would be much nicer than showing nothing at all.<br>
</blockquote>
<br></div>
I agree but the browser is probably in a better situation than the author in helping the user to install the codec needed, and the browser can do this without the element falling back to its contents.<br>
<br>
I suspect many authors would write something along the lines of "your browser doesn't support the video tag" as fallback, which is not helpful for a user with a browser that supports the video tag but doesn't have the right codec installed.<br>
<br>
If you want to, though, you can use scripting to detect that the video couldn't be played and replace the element with its contents.<br><font color="#888888">
<br>
-- <br>
Simon Pieters<br>
Opera Software<br>
<br>
<br>
</font></blockquote></div><br>