Re: typeof document.all

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.


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

Should we do that (or continue to do that; bz has a thread going)  
elsewhere? public-script-coord seems best.


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

Not only that (but yes: that -- hardly a vice in the current  
competitive world of standards, I'm sure you agree), I'd rather not  
over-specify and waste time better spent elsewhere (i.e., overpay on  
opportunity costs), and I'd rather not set a backward-looking precedent.

Let's be frank: the competitive dynamics favor lesser-share browsers  
over-specifying and greater-share ones under-specifying (or making a  
new sky castle, or version, or strict mode).

Game theory aside, the Web in ten years won't be the same as today's  
Web (compare to ten years ago -- if anything page evolution pace and  
turnover are increasing). Every single mail message about document.all  
is a missed opportunity to do something better for the standards-mode  
part of the Web. This is my biggest beef with document.all. But  
ideally we can reach agreement soon on a sufficient spec.

The lack of conformance with ECMA-262 is also an issue, not only on  
purity grounds but for implementations that did not provide for all  
the hooks needed (your masquerades-as-undefined -- yeah, yeah, it's  
"not hard"; neither are our hacks!). I've raised this in a separate  
spin-off thread on es-discuss@mozilla.org:

https://mail.mozilla.org/pipermail/es-discuss/2009-October/010027.html


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

It wasn't obvious, I agree. Sorry for not calling it out.


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

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.


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


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

I did, but again, are you scoring points by changing the context? I  
was not writing a draft spec for all browsers, I was detailing what we  
actually do? Yeesh.


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

Sorry, your reframing cheap shots are not gonna work.

To have a cross-browser spec, however underspecified, we need to hash  
out what implementations do. I was doing my part in reply to you doing  
yours. I guess you think what WebKit does is just about a cross- 
browser spec already, but it isn't.

Getting detailed concrete implementation semantics from Opera folks  
would also help us figure out cross-browser spec alternatives. A vague  
"we do sorta what WebKit does" or a "Booya!" does not help.


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

Great. Again, quit the reframing. When I hit you with a cross-browser  
detecting vs. non-detecting mode phrased in ECMA-262 terms, you will  
know it.


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

I never proposed anything someone trying to implement the behavior  
from scratch could take as a spec.

Your reframing gotcha-game stinks, frankly.

HTML5 does not yet have a spec browsers can implement from scratch. It  
lacks explicit details about all the operators. It does not conform to  
ECMA-262 and therefore it imposes purity and practical costs on  
implementations other than WebKit (and possibly Opera, but we don't  
know enough yet). And it doesn't match what Mozilla does, which does  
not mean heads you win tails we lose.


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

My view is that it's neither shameful nor only ES5's job to sort out.

But yes, we can let the specs conflict a bit longer. The main thing is  
to find new sub-specs we can agree on, starting from our  
implementations (since they are the current determinants of  
interoperation).


> It hasn't been a problem for split window, nor for this issue until  
> just now.

It is a problem for implementations that did not take the approach you  
took, and instead modeled their internals more closely on ECMA-262's  
internal methods, or simply made other choices that passed market tests.


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

/be