Re: Strategies for standardizing mistakes (was: Notes from Monday's meeting with TC39 folks)

On Oct 12, 2009, at 10:04 AM, Brendan Eich wrote:

> On Oct 12, 2009, at 12:23 AM, Maciej Stachowiak wrote:
>
>>
>> On Oct 11, 2009, at 11:48 AM, Mark S. Miller wrote:
>>
>>> I am only now catching up with this thread. Glad to see so much
>>> already covered. I'd like to begin by thanking Brendan and Mozilla  
>>> for
>>> the courage shown in this message.
>>
>> You can agree with Brendan's point of view, but whatever the  
>> merits, I don't think it shows courage to ask the standards to  
>> align with what Mozilla already does, which is essentially what  
>> he's asking.
>
> Being damned with fulsome praise is even worse than being damned  
> with faint praise in my book. Let's leave me out of it, since I do  
> not seek praise and Mozilla's compatibility philosophy is not geared  
> toward praise-seeking.
>
> However, does HTML5 not specify what WebKit does?

I think it's closer to what WebKit does than what Gecko does  
currently. Part of this may have been due to difficulty in figuring  
out what Gecko was actually doing.

> I was not "talking my book" in arguing for confining document.all to  
> quirks mode (I had forgotten that detail, as jst@mozilla.org can  
> attest from my stopping in the hallway late last week for a  
> reminder). Are you talking yours?
>
> I hope not, because we have few bits of evidence to cite, but  
> Mozilla has more market share and we emulated undetected  
> document.all earlier than WebKit did. And we did it only in quirks  
> mode, and we haven't felt any pressure to pollute standards mode  
> with it. This means more to me than any theoretical or purity  
> argument.

I haven't objected to limiting document.all (undetectability and all)  
to quirks mode. In fact I specifically said I thought it was  
reasonable. Mozilla's experience seems to indicate that most of the  
content using document.all blindly was in quirks mode. We can do some  
follow-up studies to make sure.


>
>
>> I'm willing to concede that Mozilla's behavior is arguably a  
>> smaller violation than what WebKit does. But I think the cost is  
>> that it's significantly more confusing for authors. Mozilla's  
>> behavior results in examples like this:
>>
>> var all1;
>> function foo(x) {
>>   all1 = x;
>> }
>> var all2 = document.all;
>> foo(document.all);
>> // all2 now holds undefined, while all1 holds the document.all object
>
> What we did is described by this bug (resolved, not suitable for  
> commenting):
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=248549
>
> Starting from the "return undefined for 'if (document.all)' contexts  
> but satisfy document.all.foo undetected uses" design premise, the  
> rest was almost pure phenomenology. We adjusted "detected" vs  
> "undetected" context judgments based on bytecode classes or opcodes  
> only, testing on only a few Firefox-1/2-era-beta-sized user cohorts,  
> and scored wins in the market.
>
> Such market-tested compatibility hacks can be judged harshly in  
> hindsight if they fail. If they win, they may end up standardized  
> (here we are). But they weren't done for praise, and they should not  
> be standardized prematurely or over-aggressively. This goes for  
> WebKit's and Opera's hacks as much as ours if not moreso :-|.


Sure, I don't mean to blame Mozilla for the evil of your document.all  
hack. It was a pragmatic choice in the face of unfortunate deployed  
content. I just wanted to point out that it's not obviously less evil  
than WebKit's hack, even if you can almost sort of justify it in the  
letter of the spec. It's a tough call which is worse.

(I think the WebKit version is in practice slightly less evil, because  
the results are more understandable, and it's robust against otherwise  
valid source-to-source transforms. The flip side is that it breaks the  
identities that known objects convert to boolean true, and are not ==  
to null or undefined. Though it does preserve identities that include  
an if (typeof foo == "object") check. I don't think it's an easy call,  
and I'm not sure degree of deviation from the letter of the ECMAScript  
spec is the best metric.)


> I don't want to add falsy document.all as WebKit did without more  
> discussion, and then *only* to quirks mode.

I agree with you that we should review the pros and cons of different  
approaches (probably a discussion for whatwg or public-html).

>
> For public-script-cood, I do not want WebIDL bent around this hard  
> case, which will tend to tempt WebIDL users to create more like it.  
> Hard cases make bad law (they teach in the law schools).

Right now WebIDL doesn't have anything for this case and I don't think  
it should.

> Even more important than warnings and rhetoric, IMHO, is to use the  
> quirks-mode penalty box to avoid leading novice developers astray,  
> even unintentionally according to "what just happened to work", by  
> festooning standards mode with legacy crap!

HTML5 also makes it very easy to get into standards mode ("<!DOCTYPE  
html>" is much more memorable than the prior incantations), so that  
may make it easier to benefit future standard-smode content.

On the history standards mode vs. quirks mode, I'm not as completely  
gung-ho. Some standards mode changes are improvements; they clean up  
behavior that was otherwise hard to understand, like paragraph margin  
collapsing. Others are just different, not necessarily better. For  
example, I don't see the major benefits of making class names in CSS  
case-sensitive instead of case-insensitive, or of rejecting CSS  
lengths without a unit. In some cases, it may have been better for the  
standards to change. Some standards mode differences are arguably  
worse, like the table layout issue that necessitated the creation of  
almost-standards mode.

Regards,
Maciej