Re: typeof document.all

On Oct 12, 2009, at 1:44 PM, Maciej Stachowiak wrote:

>>> Specifically, the in operator and the hasOwnProperty() method will  
>>> give different results.
>>
>> You must be talking about the other issue I failed to mention:  
>> where on the prototype chain, if not directly on the referenced  
>> object, the existent property (lazily created or not) lives.
>
> No, I'm just explicitly stating the differences from a property that  
> has value undefined from no property, which you mentioned.

Ok.

You mentioned in vs. hasOwnProperty, which in conjunction wtih  
reachable prototypes along the chain raises the other issue too: where  
does this object live (if part of the normative spec).


>>> I think using the object in a with() statement will also give  
>>> different results.
>>
>> There should be no 'with' connection. Do you have a testcase?
>
> A property with value undefined will certainly cause different  
> behavior when the object is used with 'with' than a missing  
> property. I did not mean to imply this had any relation to  
> document.all.

Oh sure -- the undefined-valued property shadows. I thought you meant  
a difference to-do with in which prototype the property was defined  
(with value undefined -- whew!).


>> Right, of course -- but is 'all' supposed to be direct (or appear  
>> to be that way), and not on any visible prototype? Or must it (by  
>> hasOwnProperty) be a direct property of HTMLDocument.prototype?
>
> According to Web IDL as currently written, I believe it should be an  
> "own" property.
>
>>
>> This seems unimportant for interoperation based on what browsers  
>> actually do so far. Must it be specified? If it must, what about  
>> making it appear to be a direct ("own" in ES terms) property of  
>> document? IIRC IE does that.
>
> I think Web IDL makes all non-method properties be "own" properties  
> currently, so I think that is what is specified.

Yes, but should these details be specified?

I realize I'm asking about leaving things unspecified. But the plain  
fact is browsers don't agree today, so this can be considered. Lots of  
specs (especially programming languages not interoperating across the  
web, e.g. C and Scheme) are under-specified intentionally to allow for  
diverse implementations and optimizations.

I didn't want to assume that document.all had to be fully specified,  
or to assume that, just because WebIDL does specify prototypes and  
"own" status, that it is not forcing over-specification in this case.


>> I'm loath to volunteer Mozilla changing to match WebKit, unsinking  
>> sunk costs and taking risks, but we might. Two issues stand in our  
>> way:
>>
>> 1. The ES-purity point of ToBoolean(Object) -> true manded by all  
>> ECMA-262 editions without host object exception, which is reflected  
>> in our implementation, so it's not just a purity issue for us (even  
>> if I'm not a purist about conformance).
>
> We had to make some minor changes to our JavaScript implementation  
> to support this. I think the changes to support the Mozilla behavior  
> would be quite a bit more extensive. The code that implements  
> property accesses on Document (or any host object property access)  
> has no way of knowing if the value will be used in a boolean  
> context, as the rvalue of an assignment, as part of an object  
> initializer, or whatever other cases behave unusually in Gecko. I  
> think we considered doing something Gecko-like back in the day and  
> decided it was more complicated.
>
> It would be useful if someone could explain the Gecko behavior in  
> detail. I couldn't figure out exactly what it does either by testing  
> or by reading the patch that implemented the behavior. Then we could  
> consider technical pros and cons of both behaviors.

Ok, but doing what you ask here doesn't address my point 1.

We classify bytecode combinations implementing if, ?:, switch, {===,! 
==,==,!=} x {null,undefined} (null or undefined only on the right of  
the operator, !, typeof, ||, &&, assignment, and property  
initialization as "detecting" and suppress lazy creation of  
document.all.

(Testing showed that assignment to variables and initialisers led to  
later detection, so we imputed detection to the = operator and the  
property initialiser in d = {all: document.all}.)

All other bytecode combinations are non-detecting and force lazy  
creation of document.all.


>> 2. The quirks mode conditioning of our undetected document.all  
>> emulation. We do not want document.all in standards mode. You  
>> agreed in principle on public-script-coord recently. Who else needs  
>> to agree for HTML5 to spec this as quirks-mode only (I may be  
>> showing my ignorance by asking, if HTML5 has no quirks-mode at all)?
>
> I think we could plausibly make it quirks-mode-only. I'd like to  
> hear input from others. HTML5 most definitely has quirks mode and  
> specifies what triggers quirks vs. standards as well as specifying  
> some specific behavior differences.

Good to hear.

/be

Received on Monday, 12 October 2009 21:39:32 UTC