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:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=253150#c5
>
> 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":
>
> 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.

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


>
>
>> 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:
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-September/009844.html

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

Regards,
Maciej