[whatwg] HTML 5 video tag questions

[Philip Jägenstedt]

On Mon, 13 Jul 2009 11:14:21 +0200, Jonas Sicking <jonas at sicking.cc> wrote:

> On Sun, Jul 12, 2009 at 11:20 PM, Ian Hickson<ian at hixie.ch> wrote:
>> On Fri, 10 Jul 2009, Jonas Sicking wrote:
>>> >>
>>> >> Hmm.. is that good? What if you want to use an <object> (to use  
>>> flash
>>> >> or java) or a <img> as fallback?
>>> >
>>> > Then you do it with script.
>>> >
>>> > The design is based around the assumption that we will eventually  
>>> find
>>> > a common codec so that fallback won't ever be needed in supporting
>>> > UAs.
>>>
>>> I agree that the current design makes sense once there is a common  
>>> codec
>>> supported across all browsers. However currently it seems like we might
>>> not reach that point until after all major browsers support <video>.
>>>
>>> What would be the downside of displaying the fallback contents if none
>>> of the videos can be displayed due to unsupported codecs?
>>
>> When would you fall back? For example, while parsing, would you fall  
>> back
>> in between the <video> element being parsed and the first <source>  
>> element
>> being parsed?
>
> You could display the fallback once you've reached the </video> and
> not found an acceptable <source>. Technically it'd be when you pop the
> video element off the stack of open elements. I don't even think it'd
> be hard to pull down all <source>s and check that none of them are
> supported before displaying the fallback if types aren't specified on
> the <source> element.

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.

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

-- 
Philip Jägenstedt
Core Developer
Opera Software