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
