Re: typeof document.all

On Oct 12, 2009, at 5:40 PM, Brendan Eich wrote:

> On Oct 12, 2009, at 4:46 PM, Maciej Stachowiak wrote:
>
>
>> One relevant question is: will future programs care about the  
>> results of operations such as hasOwnProperty() or  
>> getOwnPropertyDescriptor()? Will it make things harder for them if  
>> the results are not consistent cross-browser?
>
> If they are messing with document.all in ES5 code I wish them harm  
> (true fact! :-|).

I raised this question mainly with reference to the general case: for  
normal interfaces, should Web IDL specify how every IDL method and  
attribute looks to asOwnProperty() and getOwnPropertyDescriptor()? I  
could see a case for either approach. If we do want to do this for IDL  
interfaces in general, then we can consider the case for making  
document.all an exception. I don't see a huge reason for treating it  
differently on this particular detail.

>
>> It does seem that current code does not depend significantly on  
>> what is an own property and what is a prototype property (possibly  
>> a getter). But it seems to me that code wishing to extensively  
>> prototype-hack the DOM, or build a facade on top of the DOM, could  
>> benefit from these details being consistent.
>
> 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.

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

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

>
>> This leads me to assume by default that any browser differences on  
>> this are likely to create problems at some point (and in  
>> particular, as the bigger differences are smoothed out, smaller  
>> differences may start to matter more).
>
> This argument applies to every DOM difference, and since bug for bug  
> compatibility is impossible its absurd reduction is a single source  
> base for all browsers. But since that's not going to happen, we have  
> to draw lines well short of that mark.

In the past, the specs have fallen short of the mark in terms of  
defining what is actually pragmatically necessary. I think they can go  
further without going overboard. In the case of whether DOM attributes  
are prototype properties or own properties, I see it as a borderline  
question. But people definitely care about access to the prototype for  
purpose of observing and replacing methods.


>
>> On the other hand, there are many potential performance tradeoffs  
>> to how exactly DOM attributes get implemented. This concern would  
>> be lessened if we could show that it's possible to use a variety of  
>> implementation strategies while getting consistent output from  
>> hasOwnProperty() and getOwnPropertyDescriptor().
>
> We can and do use prototype properties with special attribute  
> combinations that make them appear per-instance. This is good for  
> shared non-configurable native-code-implemented getters bound in  
> prototypes, where the referenced property seems to be "own" when  
> tested on an object delegating to that prototype for the getter's id.
>
> ES5 discussion of Object.getPrototypeOf led us to conclude that host  
> objects can hide prototypes if they wish to, so long as they follow  
> certain rules in ES5 Chapter 9.
>
> So it seems to me we could more easily agree on hasOwnProperty and  
> getOwnPropertyDescriptor than revise our document.all emulation, and  
> allay some of your concern about metaprogramming the DOM breaking on  
> divergent browser undetected document.all emulations.

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. Once we have determined the general  
principle, we can figure out whether document.all should be an  
exception.

>> 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 do, if it is enough for real-world interop and we can fry bigger  
> fishes.

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.

>>
>> Maybe I misunderstood, but it sounded like your point 1 was really  
>> about implementation mechanics, not just a purity issue. I think I  
>> said above that the implementation mechanics were not that hard,  
>> and in text you snipped, I gave some of the details of our  
>> implementation. I don't really think either approach has full ES  
>> spec purity. Implementation difficulty is a more significant concern.
>
> Agreed, but we'll have to deal with TC39 too. I'm sure it was "not  
> that hard" to do what you did; that phrase goes for what we did in  
> 2004 with detecting vs. non-detecting bytecode contexts. We'd need  
> to scope the work.
>
> 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.

[... snip some details ...]

>
>
>> 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);
alert(x);
</script>

>
>> Also through redundant grouping parentheses.
>
> 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.

[... further snip ...]

>
> 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 don't think any of the behavior cited is  
particularly "wrong", and I certainly wouldn't expect it to cause  
compat issues. I'm just trying to understand if it's possible to  
specify the behavior without reference to the details of SpiderMonkey  
bytecode.

[... snip ...]

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

Regards,
Maciej