[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Aryeh Gregor]

On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <kit at iqmultimedia.com.au> wrote:
> 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?

Suppose browsers fell back to the contents if they couldn't play any
of the sources.  Then what happens if the browser isn't sure whether
it can play a video until it's started loading it?  This would be
extremely common -- it would happen any time the source is given with
src="", or if <source> elements are given with no type="", or even if
there was a type="" but the browser wasn't sure it supported the exact
versions or didn't fully trust the author or whatnot.  Then does the
browser not load the contents until it figures out it can't play the
video, then load the contents at some undefined later time?  So
scripts execute out of order and so on?

Or should the browser be forced to block further rendering of the page
until it knows for sure whether it can play one of the videos?  This
might require it to fetch the metadata of several videos, probably
slowing down page load considerably.  This is a bad solution as well,
especially since in the long term, one would hope that some baseline
format would be supported by all major browsers and provided by all
pages, so the forced wait would usually be pointless.

If you suggest requiring type="", and forcing browsers to guess
whether they support the video based on that, what happens if the
browser guesses yes and it turns out not to be able to play the video
after all?  Then you're back to the same unpredictable injection of
content post-load.

This is not even mentioning what happens if the list of <source>
elements changes after page load.  That could probably be handled.
But the above problems are pretty hard to avoid, as far as I can tell.
 So for now, you have to either double-encode or rely on JavaScript.
If this is too much of a sacrifice for you, then you should probably
wait a few years before you start using <video>, until support is
better -- for most authors it probably won't be pragmatically worth it
until <video> support is so good that fallback isn't necessary
anymore.