Re: Codecs for <video> and <audio>

On Tue, Jul 7, 2009 at 4:02 AM, Robin Berjon<robin@berjon.com> wrote:
> On Jul 7, 2009, at 01:30 , Ian Hickson wrote:
>>
>> The downside is that it would not match reality.
>>
>> I think it would be harmful to spec something that is actively different
>> than what a browser vendor will implement. This is why HTML5 started --
>> because the W3C wrote specs that were idealistic and did not match the
>> actual deployed landscape.
>
> At this point I'm only aware of one browser vendor having said they wouldn't
> do this. Am I wrong? Since when does a single vendor get a veto?

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.

What if Microsoft were to come along and say, "We're not going to
implement SVG". Do we then pull the SVG section? 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.

Shelley



>
> At this point we have multiple implementations of a feature that has strong
> backing in the community, and that we have no reason to believe isn't
> interoperable. That's reality. I'm all for listening to vendors, but once in
> a while they'll get something wrong and change their minds. Had we dropped
> the ball when Netscape said they would never support CSS, or the W3C DOM,
> we'd be in a worse place than we are now.
>
> If Theory really does not fly in the end, then there's plenty of time to
> remove it later. But at this point it is premature and unrealistic to remove
> it.
>

Another good, and reasoned argument.

> --
> Robin Berjon - http://berjon.com/
>    Feel like hiring me? Go to http://robineko.com/
>

Shelley

Received on Tuesday, 7 July 2009 12:16:07 UTC