Re: typeof document.all

On Oct 13, 2009, at 12:06 PM, Maciej Stachowiak wrote:

> On Oct 13, 2009, at 10:54 AM, Brendan Eich wrote:
>
>> I'm not sure this is an issue.
[snip]
>>
>> Here's an overbroad google codesearch for " === undefined":
>>
>> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ajavascript+%22+%3D%3D%3D+undefined%22&sbtn=Search
>>
>> The results here IMHO argue for conservatism in the absence of  
>> evidence, i.e., evaluating document.all in (document.all ===  
>> undefined) to undefined.
>
> This search finds only one hit for "document.all === undefined",  
> which is a Mozilla regression test:
>
> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ajavascript+%22document.all+%3D%3D%3D+undefined%22&sbtn=Search
>
> I could be convinced, but the Google code search does not seem  
> terribly persuasive.

Are you sure the codesearch I cited, for " === undefined", with lots  
of generic-looking functions, is not showing code that sometimes  
passes document.all as a parameter to one of the generic functions?  
I'm not sure of that at all, which is why I argued for conservatism.

Of course real results for "document.all === undefined" would be  
persuasive, and I did start out writing "I'm not sure this is an  
issue" as a followup to yesterday's mail promising to look into the  
=== issue further. You have to know when to quit!

So forgive me for once again pointing out the difference between what  
I wrote and what you seemed to respond to. I'm clearly not claiming  
that we must specify that (document.all === undefined) because of  
certain IE-only page compatibility knowledge, old or new (there isn't  
any, and was not in 2004 now that I've read the old bugs).

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.


>> Yes, a spec should be phrased in terms of ECMA-262's grammar. But  
>> since you said what WebKit did, my response was equally concrete in  
>> terms of SpiderMonkey. Are we done? I fear no good deed goes  
>> unpunished.
>
> The only point I wanted to establish is that "do exactly what Gecko  
> does" is probably not suitable for a spec, because the exact  
> behavior seems to depend too much on SpiderMonkey-specific details.  
> I can't even tell if you disagree with this point, since you're  
> advocating a loose spec rather than a "do what Gecko does" spec.

Come on, I don't think for a second we should spec what Mozilla  
implemented, and I said so explicitly several times, the first one  
(quoting: "I don't want to standardize what we did, but I am glad we  
did it") here:

http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0059.html

You have me wrong, I'm not "defensive" about this. I'm increasingly  
"offensive", mainly because you are not reading carefully.

I also reject your  (apparently dropped) bogus point of order that we  
must finish WebIDL's ES bindings and agree on how they work in detail  
before considering document.all as a special case, possibly  
underspecified.


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

We can do something else that underspecifies. I think we should. I'll  
work on a proposal.

The best way for you to make a proposal for ECMA-262 to allow an  
object like WebKit's document.all is to propose it more-or-less as you  
did in this thread (formalization is not required) to es-discuss@mozilla.org 
.

/be