- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 12 Oct 2009 10:37:27 -0700
- To: Brendan Eich <brendan@mozilla.org>
- Cc: "Mark S. Miller" <erights@google.com>, Simon Pieters <simonp@opera.com>, Anne van Kesteren <annevk@opera.com>, Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org
- Message-id: <B5B052C2-CCA9-4E83-8731-D0712E8F8FA8@apple.com>
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
Received on Monday, 12 October 2009 17:38:04 UTC