[whatwg] HTML 5 video tag questions

[Jonas Sicking]

On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedt<philipj at opera.com> wrote:
>>> The design you describe is what <object> tried to do, and it proved to be
>>> extremely problematic in practice -- and that was without another
>>> built-in
>>> fallback mechanism to complicate matters.
>>
>> While <object> has had a very poor implementation story, I don't think
>> this was a big reason for that.
>>
>> Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
>> answer this better, but at least in gecko I don't think this part of
>> object was particularly hard to implement correctly once we actually
>> tried.
>>
>> Has any browser vendor argued against displaying the fallback due to
>> high implementation burden?
>
> Implementation probably isn't the biggest burden here, specifying sane
> behavior is. For example:
>
> If fallback content is displayed after the last source element has failed,
> what should happen when a new source element is inserted? Switching back to
> "video mode" would make it even more special than object fallback and if you
> don't you'll just get stuck with fallback and have effectively broken the
> possibility of inserting source elements via scripts.
>
> Something like <video><source
> src="cant.play.ogg"><new-fallback-element>Ooops!</new-fallback-element></video>
> is what you'd need to make the resource selection algorithm deal with
> fallback in a sane way when scripts are disabled, but this is too much of a
> corner case to justify the complexity in my opinion.

I think fallback contents is simply defined as the contents of the
<video>, minus any <source> elements (which wouldn't render anyway).
No need for <new-fallback-element>.

The simplest solution would be to display the fallback when there
aren't any <source> (or @src) elements being either displayed or
waiting to load. I think spec-wise the simplest thing would be to
display fallback when

The networkState of the element is NETWORK_NO_SOURCE.

This way even incremental rendering of the fallback contents would
work fine. The only case that's weird is markup like:

<video>
  lots and lots of fallback here
  <source src="...">
</video>

There is a risk that content would be displayed, and then switch to
displaying video. This doesn't seem like a big problem as it seems
more likely that people will put the <source> first. And if someone
doesn't the effects aren't very bad.

Alternatively we could use the following rules:
1. The networkState of the element is NETWORK_NO_SOURCE.
*and*
2. The <video> element is fully parsed. I.e. it has been removed from
the stack of open elements.

This would mean that incremental rendering doesn't work. This doesn't
seem any worse than what we have now when fallback is never displayed.

Though I think it'd work fine always display fallback whenever the
networkState is NETWORK_NO_SOURCE.

/ Jonas