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

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 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'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 :-|.

The market among web developers, browser vendors, and users (such as  
it was; a near monopoly by 2004 when we hacked undetected document.all  
emulation, but a market that was poised to see new competition from  
Firefox) helps with "price discovery", in this case the spread between  
"bid" and "ask" prices of document.all emulation by various subjective  
measures, including how much IE tailpipe we had to smoke if we overdid  
the emulation, the opportunity as well as direct costs to implement  
and ship in time for Firefox 1.0, the opinions of Mozilla advocates  
who did not want us emulating any IE-ism (certainly not in standards  
mode [*]), and other costs and benefits.

Hardly a perfectly efficient market (no such thing exists in this  
world) but better than nothing, and better than sticking blindly to  
old de-jure or de-facto standards.

I don't want to standardize what we did, but I am glad we did it.

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

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

If document.all ends up in standards mode, I repeat that all else  
equal, document.all usage *will* tend to proliferate in standards-mode  
documents. Why should we risk this outcome without strong (or any)  
evidence that it is necessary for Mozilla-compatible or (IE /\ non-IE)  
intersection-semantics-compatible web compatibility?

/be

[*] BTW, I agree rhetoric and warnings are usually wasted on users,  
but developers are users too. Developer evangelism and beliefs can and  
do help to remake the Web. How else to explain the rise of standards- 
mode doctype declarations in the early part of this decade, much of it  
before Firefox?

The WSP folks deserve praise, so do Opera and Mozilla and other  
minority-share (at that time, very minority-share) browser providers  
who supported quirks vs. standard mode switching. But a great many  
nameless web developers (and perhaps some tools; perhaps the copy- 
paste programming technique) deserve praise for collectively moving  
the web toward standards, and demanding standards support from browser  
vendors.

https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior

is our list (I hope up to date), and as roc blogged here:

http://weblogs.mozillazine.org/roc/archives/2008/01/different_appro.html

we hope to, and sporadically do actually, reduce the set of quirks  
over time. In any event we want to avoid case explosion in our code  
(I'm sure you do too), while still putting quirks in a penalty box and  
paying some runtime logic price for the greater good (here some Opera  
folks have explicitly parted company).

Perhaps this sacrifice is what Mark was praising in what I wrote. If  
so, I'll take it with some thanks, since I do not believe we should  
optimize for implementor convenience over all else.

In working on new standards including HTML5 and WebIDL, we should not  
ignore the role of web developers. In this light, warnings and even  
rhetoric can help.

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!

Received on Monday, 12 October 2009 17:05:40 UTC