Re: Codecs for <video> and <audio>

Quoting Ian Hickson <ian@hixie.ch>:
>>
>> Robin hit on what I think is the most important point on this decision:
>> it gives veto power to a single company. That is a dangerous precedent
>> to create.
>
> The relevant implementors have veto power over the parts they are intended
> to implement whether we like it or not.
>
>
>> What if Microsoft were to come along and say, "We're not going to
>> implement SVG". Do we then pull the SVG section?
>
> Not immediately, but if we can't convince them that SVG is the way
> forward, then yes.
>
>
>> Yet your own company, Google, is creating a library to help work through
>> issues of one browser company not supporting SVG, and the same level of
>> innovation will help with the video codec, and Apple's reluctance. A
>> reluctance I imagine that won't last forever.
>
> I'm not here to make the specs do what Google wants. I'm here to make the
> specs represent what is actually implemented.

Whilst I basically agree that we should try as hard as possible to  
make specs that everyone agrees to implement, I don't think it is  
necessarily true that dropping features where unanimity cannot be  
achieved has the best overall effect for the web as a whole (that is,  
for the Open Web platform and for authors using that platform).

As an example of a case where a major vendor has refused to implement  
something, consider DOM 2 Events which is still not implemented in  
Internet Explorer, despite being almost nine years old. Now it may be  
that they have never formally stated that they are unwilling to  
implement that specification (and it may even appear in IE9) but  
actions speak louder than words, and for the past nine years the  
situation for authors has been exactly the same as if the IE team had  
announced that they would never implement it. Despite this, the fact  
that the spec exists is clearly a win compared to the spec not  
existing; in the browsers that do support the spec it has been  
possible to get interoperability, whilst libraries have been able to  
use specific workarounds for IE alone. Having to learn 1 set of rules  
and one set of exceptions is clearly better than having no way to  
achieve the same thing or having to learn N (>2) different sets of  
rules.

I stress that the comparison of interest is only between the current  
situation and the point of view that you have advocated here - pulling  
features that some browsers refuse to implement. It is possible that  
in the specific case of DOM 2 Events there could have been a better  
attempt at finding a mutually agreeable spec. That possibility does  
not change the relevance of the comparison between what actually  
happened and future situations where one player does not implement a  
specification.

I note that this example is not unique. There are many parts of the  
web technology stack that are not unilaterally supported in browsers  
today and which some browsers do not seem to be interested in working  
on (SVG is another good example). Nevertheless these features can have  
value in the browsers where they are supported, and having a  
specification for the features helps create interoperability between  
the implementations that exist. This puts authors in a much better  
position than they would be in if we adopted the policy of just  
throwing out parts of the specification that a minority of vendors  
will not commit to (to take this point to its extreme, not so long ago  
Microsoft refused to work on their browser implementation at all. If  
they had announced this publicly I would not expect all spec work  
relating to web browsers to have ceased; indeed I would hope that it  
would have focused people on improving the competition to route around  
the damage).

(Note: None of this is supposed to represent a position on the video  
codec issue. My opinion on that issue is that we should reinsert a  
note like the one we had before since people are still exploring the  
options for a RF baseline codec. I don't know how this sits with W3C  
process if we want to go to LC though).

Received on Wednesday, 8 July 2009 19:29:14 UTC