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


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

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC