Re: typeof document.all

On Oct 13, 2009, at 10:54 AM, Brendan Eich wrote:

> On Oct 13, 2009, at 3:28 AM, Maciej Stachowiak wrote:
>> On Oct 13, 2009, at 1:11 AM, Brendan Eich wrote:
>>> On Oct 13, 2009, at 12:32 AM, Maciej Stachowiak wrote:
>>>>> For document.all, which is also falsy (not just in  
>>>>> ToBoolean(document.all) -> false as I thought, but also in being  
>>>>> == null and == undefined as you wrote -- and === as well I  
>>>>> presume), special care will be needed.
>>>> It's specifically *not* strict-equal to null and undefined, at  
>>>> least in WebKit.
>>> Why not === undefined if the object masquerades as undefined?  
>>> JSLint has caused some document.all === undefined tests to arise,  
>>> if my memory serves (I will have to check tomorrow).
>> We're not aware of any problems with it, but they could be latent  
>> bugs, and it's certainly something we can change.
> I'm not sure this is an issue. The Firefox pre-1.0 undetected  
> document.all support evolved from not supporting === undefined at  
> first, to supporting it as we've discussed, with history recorded in  
> this bug, where the === undefined idea was raised in the linked  
> comment:
> I recall suspecting at the time that JSLint or the teachings that it  
> reflects, which favor fanatical use of === over ==, would leave some  
> document.all tests broken if we didn't support === undefined.
> Here's an overbroad google codesearch for " === undefined":
> 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:

I could be convinced, but the Google code search does not seem  
terribly persuasive.

>> I'm still hoping to come to a conclusion about the general case of  
>> where Web IDL properties live.
> Should we do that (or continue to do that; bz has a thread going)  
> elsewhere? public-script-coord seems best.

Yes, public-script-coord would be better.

>>> ECMA-262 does not specify abstract syntax at all. If there were a  
>>> bytecode for the comma operator (it would be a nop), it could be  
>>> skipped (we used to do exactly that for decompiler support). So  
>>> either way, comma is doable.
>> I think if you want to actually specify the behavior, you have to  
>> mention what happens for parens and comma, even though they are not  
>> represented in SpiderMonkey bytecode. Other engines may not have a  
>> sufficiently-similar bytecode stream to peek at.
> Let's stop fencing over minutiae. I was clearly describing what  
> SpiderMonkey does. As I noted, it even used to have a JSOP_GROUP no- 
> op, which the detecting code skipped.
> 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.

It's not a matter of point-scoring, it's a matter of considering the  
possibilities and eliminating ones that don't seem to work. Please  
don't be defensive. 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  

>> I'm generally against making the spec more open-ended, but I don't  
>> have a very strong case against it in this particular instance. I  
>> would like to hear some input from people besides the two of us.
> Anne replied, but I still do not know exactly what Opera does.  
> Vagueness does not help here. Your list was good (explicit mention  
> of === undefined not evaluating to true would be great). I'd  
> appreciate the same from an Opera person -- I'll see if some old  
> contacts who've hacked on Futhark can help.

I talked to Anne and James Graham about this on IRC last night. From  
their report, and from testing, I believe Opera implements the exact  
same three exceptional behaviors for the all collection that I listed  
for WebKit.

[... large snip ...]

> HTML5 does not yet have a spec browsers can implement from scratch.  
> It lacks explicit details about all the operators.

I think the idea is that no operations are modified other than the  
ones mentioned.

>>>> So I think the options for document.all are: (1) design a variant  
>>>> of the Gecko behavior that is suitable to put in a standard; (2)  
>>>> go with something closer to the WebKit behavior;
>>> Who says (2) is suitable to put in a standard? The HTML5 draft  
>>> explicitly acknowledges that it does not conform to ECMA-262.
>> I don't think conflicting with ECMA-262 is a showstopper for  
>> putting something in HTML5.
> You didn't call it a showstopper, but you raised it as an issue and  
> laid it at ES5's feet:

Yes, I think it's a problem, but not one that would lead us to stop  
the presses on either ES5 or HTML5.

>>>> (3) write the spec loosely enough that either behavior is  
>>>> conforming, but the spec gives enough guidance that you can  
>>>> implement sufficiently compatible behavior by reading it;
>>> In case it's not clear, I'm favoring 3. Wait, it was clear. :-/
>> It wasn't clear to me, but thanks for being clear now.
> How many times do I have to call explicitly for underspecifying?

I think your position is crystal clear now (to me at least, and I hope  
to everyone else).

>> I don't think there is anything seriously wrong with this option,  
>> though I'm not sure offhand how to describe the required behavior.  
>> Do you have a suggestion for how this could be written up?
> I'm trying to get to one, if you can stop trying to "win".

I would ask you to assume good faith, in the interests of productive  


Received on Tuesday, 13 October 2009 19:06:57 UTC