Re: Conflicts between W3C specs and ES5?

On Nov 18, 2009, at 1:01 AM, Anne van Kesteren wrote:

> Your overall line of thought is pretty clear to me now. Thanks for  
> elaborating on it. I just wanted to reply to a few points.
>
> On Mon, 16 Nov 2009 19:08:06 +0100, Brendan Eich  
> <brendan@mozilla.org> wrote:
>> Opera peeps other than you with whom I've spoken (ok, over beer ;-)
>> have confessed to occasionally committing too much reverse-
>> engineering, sometimes resulting in blow-back where Presto had to
>> follow IE "a bridge too far". This seems to be a real issue. We do  
>> not
>> live in a Utopia where everyone wins by specifying and then
>> implementing everything in nearly-infinite time.
>
> We have indeed reverse engineered too much of IE in the past and  
> have removed quite a bit of that in the last couple of years. I  
> think a lot of that could be done in part because Mozilla gained  
> more market share. On the flip-side, we now copy proprietary Mozilla  
> features instead... E.g. Range.createContextualFragment(). :-)

Since almost the start of the WebKit project (when WebKit was still  
internal to Apple, and IE had around 90% market share) our usual  
approach has been:

1) Try just implementing the standard.
2) When/if that turns out not to be compatible enough, try reverse  
engineering Mozilla.
3) When/if that turns out not to be compatible enough, try spoofing  
the UA string of a Mozilla browser (we do this much less often these  
days).
4) When/if that turns out not to be compatible enough, try reverse  
engineering IE.

We took this approach not because we had a huge crush on the Mozilla  
Foundation (ok, maybe a bit of a crush) but simply because Mozilla was  
closer to the standards, much easier to reverse-engineer (due to  
source availability and easier to understand behavior), and likely to  
experience a future growth trajectory. So kudos to Mozilla for that;  
Gecko did a lot to pave the way for a more competitive browser market  
and a more standards-compliant Web.

This being said, there were a lot of things that were just completely  
unspecified, or where the spec outright lied, and the cost of reverse  
engineering was fairly high. Nowadays, compatibility is less of a day- 
to-day issue. But remembering that pain makes me lean pretty strongly  
to specifying or at least documenting the legacy, and even more so  
towards removing implementation requirements that directly contradict  
what you really need to do to render the actual Web. But I am not an  
absolutist about this - I'll concede there may be some legacy features  
that are better abandoned, if we truly work at phasing them out. And I  
think CSS2.1, HTML5, ES5 and other recent specs have made huge strides  
in better aligning the standards with reality. But I think there are  
still more things we can do where the benefit exceeds the cost.

Regards,
Maciej

Received on Wednesday, 18 November 2009 09:59:09 UTC