W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] HTML 5 video tag questions

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 13 Jul 2009 00:47:12 -0700
Message-ID: <EFC45CE1-6738-401F-9E50-5EA389E293FC@apple.com>

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.

Received on Monday, 13 July 2009 00:47:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC