W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: typeof document.all

From: Brendan Eich <brendan@mozilla.org>
Date: Tue, 13 Oct 2009 15:40:09 -0700
Cc: HTML WG <public-html@w3.org>
Message-Id: <D583FDFF-58AC-46FD-97EC-B4A7CB2731C1@mozilla.org>
To: Maciej Stachowiak <mjs@apple.com>
On Oct 13, 2009, at 2:33 PM, Maciej Stachowiak wrote:

> I'd really like to keep this conversation courteous and on the  
> technical level. Treating every point of technical disagreement as  
> an attack is not a good way to do that. Can we please do our best to  
> assume mutual good faith?

I will do my best! My objections are not about bad faith, though. But  
hey, I'll not quibble.

>> I am suggesting that the more conservative course of treating  
>> (document.all === undefined) is justified in light of all the  
>> generic-looking "foo === undefined" testing that the codesearch I  
>> cited discloses.
> It's not a completely crazy rule to apply, but it's not obviously  
> needed either. I'm indifferent to whether we enshrine this behavior  
> in the spec. I don't think it would be a huge problem to implement  
> it in WebKit, if we had to.

I see your point: if we have an object that masquerades as undefined,  
you might want === to compare object identity, as for all other  
objects. Given your approach of using an object with non-ECMA  
semantics, keeping === comparing object identities pending evidence  
that IE-only web page compatibility needs (document.all === undefined)  
is plausible and could be a good thing.

Indeed are you indifferent or would making (document.all ===  
undefined) deoptimize your === code? Maybe it doesn't matter; == is  
much more commonly used with any operands, although JSLint and Doug  
Crockford's book evangelize === exclusively as the replacement for ==,  
and I've seen more code using === over time on the public web.

> What I did say on this topic is: (a) as a matter of present fact,  
> Web IDL specifies which properties are own properties and which are  
> on the prototype; (b) we may want to consider the general case of  
> this (should it be specified at all? If so what should the spec  
> require?) before considering the special case of document.all. I  
> think your restatement is not a fair characterization of what I said.

In http://lists.w3.org/Archives/Public/public-html/2009Oct/0353.html  
you wrote:

"Well, there's the general question of whether Web IDL should specify  
things to this level of detail for normal properties (which is a Web  
IDL question), and then if it does, the question of wether HTML5  
should be more loose for document.all specifically (perhaps by  
defining it completely outside IDL). I don't think document.all has a  
special need to be more loosely specified in this regard than other  
DOM attributes."

I'm not sure where I went astray in reading your meaning. I don't  
think "and then if it does" is logically necessary for us to answer  
the question of whether HTML5 should be more loose for document.all  

>>> I snipped all the other instances where you got irked at me for  
>>> pointing out that the exact Gecko behavior is (in my opinion) not  
>>> suitable to put in a spec as-is. No one is advocating that option  
>>> so it doesn't seem important to discuss. If you do want to  
>>> advocate a "do what Gecko does" spec then we can come back to this  
>>> conversation.
>> I think your dilemma of "WebKit or Gecko" is a false one. But if  
>> you keep rehashing things, or failing to read what I wrote several  
>> times, we'll never find an alternative.
> I never presented those two options as the only alternatives. You  
> may recall I listed five viable options for what we could do to the  
> spec, one of which was the one you liked.

I remember, but your 4 and 5 were kinda straw men in the best sense,  
meant to be knocked down by consensus (and I agreed with you about  
them being undesirable).

Meanwhile, item 3 (the hoped for "third way" or new alternative, not  
over-specified) was what I wanted to reach by trading descriptions of  
what our respective implementations (1 and 2) did, in response to your  

"It would be useful if someone could explain the Gecko behavior in  

here: http://lists.w3.org/Archives/Public/public-html/2009Oct/0351.html.

But soon enough my iterative, informal explanation of what Gecko does  
became grist for your "not suitable as a spec" mill. See what I mean?

Received on Tuesday, 13 October 2009 22:41:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC