[whatwg] HTML 5 video tag questions

[Philip Jägenstedt]

On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> 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.

Right, anything but irrevocable fallback would make this even stranger  
than object fallback. Let's not go there.

>> 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

See below for why we can't put the fallback attribute on the video element.

> <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.

This would only cause fallback to be used when the source element is  
rejected up front, not if it is a candidate for the resource fetch  
algorithm that fails to fetch/play. So you also need to check @fallback  
before step 6. However, by then the source element may very well be  
removed from the DOM, so I you'd have to assign @fallback to a variable  
earlier in the algorithm and check that.

This approach is implementable in my guesstimation, but I'd really want to  
know more about the history of object fallback issues. Should fallback  
content be treated as if it were display:none, or are there nastier hacks  
involved?

> 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).

That would cause the fallback to be triggered unconditionally during  
parsing:

<video fallback>
<source src="foo" type="video/x-unsupported">
<!-- steps 8-10 run here -->
<source src="bar" type="video/x-supported">
</video>

There's nothing in the resource selection algorithm that's special-cased  
for static markup by hooking into the parser, which would be required to  
make it work (but then only for static markup). Putting @fallback on the  
video element just won't work.

-- 
Philip Jägenstedt
Core Developer
Opera Software