Re: typeof document.all

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


>> You can't treat this property's value like any saner object, even  
>> if you can assume it is "own" in document or  
>> HTMLDocument.prototype. Is its property-home really that important  
>> in light of its unusual value-semantics?
>
> I don't think I can make a case that specifically for document.all  
> this detail is important. But I think we should consider the general  
> case first, and that is what I was trying to do above.

Let's deal with document.all. We can hash out prototype bindings in  
public-script-coord, if they aren't already addressed in the WebIDL  
draft. I'm fine with what you've described for the general case. The  
entire point of this thread is document.all in particular, so onward.


>>> In the past, we have learned that it's required to have global  
>>> properties of the Window object with names like "HTMLInputElement"  
>>> and properties named "prototype" which hold the prototype to be  
>>> used for HTML input element instances, even though this was not  
>>> spelled out by former specs.
>>
>> Isn't HTMLInputElement a replaceable property of the window object?
>
> It is indeed. But my point was that people depend on the interface  
> objects and their .prototype properties being there, so they can do  
> their prototype-hacking thing. I don't think the prototype-hacking  
> crowd is deeply concerned about program integrity.

Nor are such hackers concerned about document.all prototype-hacking,  
because document.all is simply not prototype-hackable in current  
browsers. So this is not an issue.


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


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


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


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


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


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

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.


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


> (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. :-/


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

/be

Received on Tuesday, 13 October 2009 08:12:56 UTC