[whatwg] HTML 5 video tag questions

[Tab Atkins Jr.]

On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedt<philipj at opera.com> wrote:
> I thought you meant
>
> <video>
>  <source fallback>
>    fallback content here
>  </source>
> </video>
>
> I would prefer if fallback content and source elements weren't mixed on the
> same level, but maybe that's just me.

Eh, fallback content for non-<video> browsers is already there, so
it's nothing new.

>> (You could also just put @fallback on the second <source> and drop the
>> third <source> entirely for the same effect.)
>
> Once the source element is iterated by the resource selection algorithm and
> starts loading, the fallback attribute or the whole source element might be
> removed. You would have to set a flag at some point to remember the fallback
> state and unset it... when? What is the effect of
>
> <video>
> <source fallback>
> <source src="cant.play.ogg">
> fallback here
> </video>
>
> ?

It would hit the first <source>, note that there's no @src, see that
there is @fallback, and immediately drop to showing fallback content.

> Is fallback irrevocable or could the same video element go back to showing
> video under some circumstances?

It should be revocable in the exact same circumstances that a <video>
element might start playing from one <source>, and then switch to
another.  From my reading of the algorithm I don't think this is
possible, so fallback would be irrevocable.

> Does audio also have fallback content?

It uses <source> and the same source-selection algorithm (and the same
fallback situation in the case of non-<audio> browsers), so yes.

>>> This is why I suggested <video><source
>>>
>>> src="cant.play.ogg"><new-fallback-element>Ooops!</new-fallback-element></video>
>>>
>>> I still think the use of this is questionable though.
>>
>> I'm not sure why you think the usecase is questionable.  It seems
>> pretty clear - it'd be nice to have a non-script way of showing
>> content (specifically, alternate video players) when the browser
>> supports <video> but can't play any of the provided sources.
>
> Yes, handling the (minor) use case video support + no supported source + no
> script would be nice, but only if it doesn't make an even bigger mess of the
> resource selection algorithm and doesn't allow switching back and forth
> between video and fallback.

>From what I can tell of the resource selection algorithm, fallback
should be irrevocable, just like a successful <source> load is.

The resource selection algorithm appears to need fairly trivial
changes to accommodate this.  Step 4, when parsing @src from <video>,
insert a new substep between substeps 2 and 3.  Pull the first
sentence from the current substep 3 into this new substep, and say
something like "If the element has a fallback attribute, abort this
algorithm immediately and display the fallback content."  When parsing
<source> elements, change step 3 so that whenever any of those
conditions are met, if the <source> has @fallback the algorithm aborts
immediately and shows the fallback content, otherwise it fires the
error event and jumps to the "search loop" step as normal.

Alternately, we could just put @fallback always on the <video> element
directly, rather than on <source>.  That would preserve the first part
of what I said, but now we have a step between substeps 9 and 10 that
checks for @fallback on the <video>.  If it finds it, it immediately
aborts and shows the fallback content, otherwise substep 10 proceeds
normally (waiting forever).

~TJ