[whatwg] HTML 5 video tag questions

[Maciej Stachowiak]

On Jul 12, 2009, at 11:20 PM, Ian Hickson wrote:

> The design of <video> from the ground up is based on the idea that in
> browsers that support the element, the API will be used. If we  
> change this
> assumption, then the entire design of the element would have to be
> reconsidered -- in particular, I think we would need to find a way to
> avoid people having to implement the script side twice, in such a
> scenario. We don't get a consistent design if we change the  
> assumptions at
> the slightest provocation. In practice I don't think that the  
> assumption
> is wrong on the long term, though it may be tested on the short term.

<video> supports fallback to content that almost certainly has a very  
different API, in browsers that don't support <video> at all. I'm not  
sure why it would require major changes in the design to do such  
fallback in browsers that support <video>, but not the requested  
codec. It's true that it may be necessary to have multiple paths in  
your script if you use <video> that way. But you have to do that  
anyway, if you want to support browsers that don't have <video> at  
all. And in the case where you just want to embed a video using the  
best mechanism available, without scripting, the current design makes  
things harder. I think this argument holds up even if there is an  
agreed baseline - not everyone may want to use it, especially as the  
state of the art in video compression improves and higher resolution  
videos become more popular.

I don't think this is an urgent issue, because we probably still have  
time to change. But I think the spec took the wrong path here and your  
argument above is not very persuasive.

Regards,
Maciej