Re: typeof document.all

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.

>
>> Again, my concerns are primarily about whether this level of detail  
>> is specified for DOM objects in general. Sorry if I was unclear on  
>> that. I don't want to decide the general principle based on  
>> document.all - hard cases make bad law.
>
> Hey, I said that (http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0059.html 
> ) :-P.
>
> Great, can we get to the specific case that is the subject of this  
> thread?

I'm still hoping to come to a conclusion about the general case of  
where Web IDL properties live. I think the cost of making document.all  
an exception is low, but I think the benefit is also low. You have  
made a good case that the cost is low, the only benefit you really  
cited is that you'd rather not change Mozilla's behavior.


>> If for some reason it's way harder to follow Web IDL guidance on  
>> what is an own property and what is a prototype property for the  
>> "all" property of the document object, then that may be a  
>> reasonable choice. This particular detail seems like one of the  
>> least important aspects of document.all behavior to me.
>
> Me too, which is why I suggested underspecifying it, which means not  
> specifying document.all in HTML5 using WebIDL as you noted somewhere.

Underspecifying doesn't have to involve not using Web IDL, but it  
could. I'm not sure we have consensus that underspecifying is the  
right solution.

>
>
>>> Separately, someone has to come up with a proposal for ES-Harmony  
>>> if we want standards conformance.
>>
>> Can you point me to the resources that describe the process for  
>> that? I can consider writing it up.
>
> Will send separately.
>
>
>>>> What about the comma operator? I noticed in testing that  
>>>> "detecting" taint seems to propagate through comma.
>>>
>>> Testcase? You may be seeing dead code elimination instead of what  
>>> you think you see.
>>
>> <script>
>> var x = (alert("x"), document.all);
>
> You're assigning document.all to x, so this is a detecting case as  
> noted previously (assignment and property initialization in an  
> object initialiser).

Which is what I meant when I said '"detecting" taint seems to  
propagate through comma'. It wasn't obvious from your original summary  
of the behavior that this would happen.

>
>>> Parentheses around expressions are not part of the abstract syntax.
>>
>> I agree in principle, but at least in 3rd edition the grouping  
>> operator had its own pseudo-code operational semantics.
>
> 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.

>
>
>>> People who bother to detect document.all usually just test its  
>>> falsiness. If they pedantically compare it to something, it's ==  
>>> null or undefined, or maybe === undefined (to pass JSLint). We  
>>> never discovered pages needing more.
>>
>> Sure, I'm not asking these questions to point out bugs in the  
>> Mozilla implementation
>
> I know; I'm detailing our experience not because I worry about bugs,  
> rather to suggest how little machinery is needed to support  
> undetected document.all and increase the number of IE-assuming pages  
> that "work".
>
> Over-specifying document.all emulation could "clean up" some browser- 
> specific behavior in cases that aren't actually required for IE-only  
> pages to work. I don't think this is a good use of time if we can  
> agree on a less restrictive spec.

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.

>
>
>>> This is not something I would standardize, as I wrote on public- 
>>> script-coord, in fact it's an unintended consequence.
>>
>> Indeed, it sounds like the Gecko behavior as-is would not be a  
>> great candidate for standardization; the precise behavior seems to  
>> depend on SpiderMonkey implementation details.
>
> That's overstated. I listed abstract postfix bytecode, almost all  
> corresponding to operators in the language, without naming any  
> SpiderMonkey C++ identifiers.

You mentioned "dead code elimination" and "bytecode selection" as  
things that could affect the results. Those are not things that can be  
reasonably put in a spec. Depending on an abstract postfix bytecode  
does not give an obvious answer, without describing how the JavaScript  
language is converted to that bytecode.

> It's equally true that masquerades-as-undefined depends on JSC  
> (WebKit) implementation details at present. Are we making progress  
> by trading these kinds of statements? I don't think so.

The implementation depends on implementation details (obviously) but  
the behavior can be fully specified without reference to our  
optimization passes, or the ordering of bytecodes. I believe the JSC  
behavior could be emulated with full fidelity based on my few brief  
statements of the differences from normal objects. I don't think  
SpiderMonkey's behavior can be specified so succinctly; your attempt  
at it left some details unclear that would not have been obvious to  
someone trying to implement the behavior from scratch.

>
>> 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. It hasn't been a problem for split window, nor for  
this issue until just now.

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

>
>> (4) have the spec give enough of a blank check that either behavior  
>> is conforming, without any restrictions (so for example making  
>> document.all a completely normal property would also be OK); (5)  
>> have the spec completely ignore this issue.
>>
>> I'm not a huge fan of (4) or (5) on that list.
>
> I'm not until we spend so much time on this retrograde issue that  
> more forward-looking spec work languishes. :-|