Re: Conflicts between W3C specs and ES5?

On Nov 16, 2009, at 8:07 AM, Anne van Kesteren wrote:

> On Mon, 16 Nov 2009 16:56:14 +0100, Brendan Eich  
> <brendan@mozilla.org> wrote:
>> On Nov 16, 2009, at 7:51 AM, Anne van Kesteren wrote:
>>> Opera has similar evangelism efforts and I'm sure other browser  
>>> teams do too (at the very least Microsoft does). At some point you  
>>> just reach the point where spending some time on defining trailing  
>>> edge stuff outweighs the cost of trying to evangelize each site  
>>> that uses it.
>>
>> At some point *you* do. So do we, but less so since gaining more  
>> market share starting with Firefox 1 in 2004. Back in 2001 we would  
>> either do what we had to, or wave the standards flag and hang tough  
>> at small-percentage market share numbers.
>
> We're talking about features here that Gecko/WebKit/Presto/Trident  
> have in common.

Not in common -- just reverse-engineered enough to pass certain tests.  
Are those tests even still relevant on the web? If we assume so we can  
easily perpetuate bad forms both in implementations and (because of  
risk someone depends on the bad form in new content) in web content.

More below. The point here is that these "features" are not all  
coherent, designed artifacts with complete intersection semantics  
among browsers, based on intelligible intentions. Some are based on OS  
and libc vagaries. Some are purely accidental, and not happy  
accidents. Many are error prone and (therefore) obsolete.


> If you can remove them I'm sure that might make it more realistic  
> for us to consider removing it too rather than figuring out how you  
> implemented it. :-)

Yes, we (Mozilla) will play the other side of Prisoner's Dilemma more  
over time and "defect" from our truce-by-reverse-engineering with  
y'all. Specifically we will try to remove bad old non-standard forms,  
and not just in ES5 strict mode.

Lucky us! Hold down the fort while we make our break. :-/

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.


>> Market dynamics and content evolution mean that the trailing edge  
>> trails off -- the '90s web does not entirely render compatibly in  
>> an HTML5 UA. We should not over-bias for the past, or we will paint  
>> ourselves (slowly) into corners.
>
> 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)

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.

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

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.


> It was also said that defining an HTML parser would be a bad idea  
> for similar reasons,

No, not for similar reasons. If only a few sites use foo.arguments,  
but a great many or even most sites require residual style or other  
HTML/CSS error corrections, there is a difference in degree that you  
can't ignore.

There's a difference in kind too: foo.arguments is overlong and  
unnecessary, and content authors active these days don't intentionally  
write it, since just arguments works. It has tended to be selected out  
of the evolutionary process. It has low observed survival advantage  
compared to many of the errors for which HTML5 standardizes automatic  
corrections.

Further, the presence of foo.arguments at one notable site reflects no  
ongoing likely mistake ("oops! I typed too foo.arguments when I meant  
to type just arguments!"). Rather, the history as I recall is that it  
is a poorly-reproducing meme spread only in 1995 or early 1996 by  
draft-quality Netscape docs. It has (AFAICT, please correct me if you  
see current books or docs advocating it) almost died out.

In contrast, error-correcting HTML parsing matches error-prone human  
hand-authoring that recurs all the time, since natural language  
parsing by human readers tolerates some unbalanced nesting and other  
such correctable and apparently-likely human errors.

Some of the HTML5 correction details may be overspecified, but the  
general solution fits a real problem, which XHTML utterly failed to  
address.


> but I think it turned out as something really great and useful.  
> There may very well be a trade-off, but I have not encountered that  
> point yet personally.

HTML parsing analogies break down on trivial inspection. Let's stick  
to specifics. Otherwise you'll argue that the tasty lunch I bought you  
last year proves that all lunches everywhere are free. :-)

/be