Re: Conflicts between W3C specs and ES5?

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(). :-)


>> I'm not really convinced it takes that much time in general and e.g.
>> with ECMAScript date parsing I really think it ought to be defined
>> properly.
>
> Are you kidding? We can't even get IE to agree with the non-normative
> Annex B Y2K-buggy Date methods:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=82354
>
> Here is your chance to make things "more realistic" by demonstrating
> rather than asserting. Consider first that ES1 left Date.parse
> implementation-defined because even in 1997 it was a non-interoperable
> mess. Then consider this bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=273292#c15 (read the
> whole bug)

I'll note that you fixed the incompatibility issue pointed out in comment  
15. It also seems that any new implementation of ECMAScript that wants to  
work with those sites needs to have the same crappy parsing rules. You  
compared my HTML parser example with foo.arguments, but comparing it with  
this seems much closer, since a lot of sites use Date parsing.


> Is my head starting to fly off my shoulders at your insouciance?
> Here's why:
>
> We at Mozilla gained market share when no one thought it was possible,
> and we did it without reverse-engineering Date.parse, or a bunch of
> other cruft that apparently didn't matter enough. (We did however
> implement undetected document.all support. We chose our battles.)
>
> This means more than any armchair assertion that it would not take
> "that much time". The greater good may demand some over-specification,
> but web developers have dealt with browsers as they are, and a fully-
> specified Date.parse was not required for the rise of Ajax any more
> than for the rise of Firefox and the return of the browser wars. This
> suggests limits on specification; it says there are trade-offs.
>
> Once again it seems there is a utopian belief in complete and correct
> specs. I invite you to study Goedel's Incompleteness Theorem first,
> then consider the problem of scarcity that motivates all human,
> animal, plant, and even mineral (crystals!) economic activity.
>
> Frankly, it's silly to detail every possibly-specifiable function
> implemented half-consistently by some subset of browsers. We have
> better things to do with our time (I do, at any rate).
>
> Where to draw the line? I'm not arguing about exactly where, only that
> there is a line and anyone who would waste time crossing its most
> obvious thresholds needs to do the work in detail.
>
> If you are an Ecma member, you'll also need to convince the TC39
> members that it's worth consisdering taking your extra spec work into
> the standard, which also has its costs and benefits to trade off.
>
> I get the sense from words you and Hixie have written recently that
> there is no line -- that there are no trade-offs, only unmixed
> blessings from spec-till-you-drop. That is so obviously false in
> general that I wonder what's supporting it in particular. Perverse
> incentives in the current market game theory, I suspect.

The line presumably lies with finite resources. So you work on what you  
think is somewhat important and has some chance of succeeding. I can  
certainly see the point in not wanting to specify wacko details of Date  
parsing and legacy String method nonsense (from the bug you pointed out by  
the way I got the sense you made them work again just because IE had them  
and there was a test out there, did I miss something?) but on the other  
hand each new ECMAScript implementation intended for the Web will have to  
deal with them. And every now and then new ECMAScript implementations will  
be made.


> I'm a whatwg.org founder, but I never signed up for endless trailing-
> edge patrol. The idea was to do HTML5 instead of XHTML and improve
> browsers incrementally, and quickly. (Not by 2022.)

It seems to me browsers are evolving incrementally with specified HTML5  
features and quite quickly. But just as with e.g. CSS2 it will probably  
take a while before all the details are sorted out.


> Detailing Date.parse does not improve anything at this point. ES5
> standardizes ISO-8601-based Date parsing and developers who want to
> count on that will demand it from browsers. At least there's a sane,
> existing spec.

There's certainly a clear path for developers, but not for browsers having  
to deal with legacy code (in this case). I think both are important for  
the success of the Web platform.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 18 November 2009 09:02:45 UTC