Re: typeof document.all

On Oct 13, 2009, at 3:40 PM, Brendan Eich wrote:

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

It's possible it would slightly deoptimize it, in some cases. The  
impact would depend on how readily we can segregate objects that  
masquerade as undefined from normal objects, which are cheap to  
compare with ===. I haven't studied in detail. So I guess I'd rather  
not do it unless it turns out to be needed.

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

Is there a substantial overlap between sites that use JSLint and sites  
that use document.all? That's the bit I'm not sure of.

Note: in WebKit, ("all" in document) is true. We could very easily  
make it false, and that might be a slight compatibility boost too.  
Could not find much evidence of that construct on Google Code Search,  
even though it is arguably the cleanest way to do feature detection.

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

I think it's sensible to proceed from general cases to specific cases,  
but I don't think it's mandatory in all cases. It happens to be how I  
thought about the problem in this case.

>
>
>>>> 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 statement:
>
> "It would be useful if someone could explain the Gecko behavior in  
> detail."
>
> 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?

Perhaps this was naiive, but I thought there was a chance that the  
Gecko behavior might be something that *was* suitable to spec, and  
which might be reasonably straightforward to implement, in which case  
if we all agreed to implement it we could have world peace and  
interoperability and all that good stuff. No offense was intended in  
pointing out that this wasn't the case, and yes, in total fairness,  
you never suggested that the spec should demand Gecko behavior.

Regards,
Maciej

Received on Tuesday, 13 October 2009 22:52:49 UTC