- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 13 Jul 2009 00:47:12 -0700
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
Received on Monday, 13 July 2009 00:47:12 UTC