[whatwg] HTML 5 video tag questions

[Philip Jägenstedt]

On Mon, 13 Jul 2009 21:28:45 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedt<philipj at opera.com>  
> wrote:
>> On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr.  
>> <jackalmage at gmail.com>
>> wrote:
>>
>>> On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky<bzbarsky at mit.edu> wrote:
>>>>
>>>> Philip Jägenstedt wrote:
>>>>>
>>>>> It would have to be part of the resource selection algorithm. Since  
>>>>> that
>>>>> waits for new source elements indefinitely, when exactly would you
>>>>> decide to
>>>>> switch to fallback content? Bad solutions include special-casing  
>>>>> static
>>>>> markup and/or (falsely) assuming that scripts will not insert more
>>>>> source
>>>>> elements at some point. If fallback content is defined simply as the
>>>>> content
>>>>> of the video element I also can't figure out any other solutions.
>>>>
>>>> A <source> that says "use the content"?
>>>>
>>>> -Boris
>>>>
>>>
>>> Ie inserting <source fallback> or <source contents>.  If both @src and
>>> @fallback are specified on a <source>, it is treated like a <source
>>> src><source fallback>; that is, it first tries the @src attribute, and
>>> if that doesn't work, then it goes to the fallback content.
>>
>> That would require the parser to inspect an attribute to determine if  
>> the
>> element is a void element (one that does not have a closing tag) or not,
>> which I've been told is not very nice. Are there any other such cases?
>
> Hm?  I'm not sure what you mean here.  It would work like this:
>
> <video>
>   <source src="foo">
>   <source src="bar">
>   <source fallback>
>   <p>I'm some fallback content!</p>
> </video>
>
> You'll see the <p> if the browser doesn't support <video>, or if the
> resource selection algorithm hits that third source and hasn't found
> anything it can play yet.  It wouldn't change whether the <source> is
> a void element or not.

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.

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

?

Is fallback irrevocable or could the same video element go back to showing  
video under some circumstances? Does audio also have fallback content?

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

The browsers that have already shipped with video don't support fallback  
but they are the ones that are the most likely to need it (assuming that  
format support will get better over time). It would be nice to hear what  
they think about all of this.

-- 
Philip Jägenstedt
Core Developer
Opera Software