- From: Brendan Eich <brendan@mozilla.org>
- Date: Tue, 13 Oct 2009 14:52:57 -0700
- To: hallvord@opera.com
- Cc: Anne van Kesteren <annevk@opera.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On Oct 13, 2009, at 2:16 PM, hallvord@opera.com wrote:
> Siterer Brendan Eich <brendan@mozilla.org>:
>
>>>> How is that not what you called a "weird result"? It's similar
>>>> to what we do in assigning undefined, i.e., treating assignment
>>>> as "detecting".
>>>
>>> Having the object evaluate to false does not seem so weird to me.
>
> Just chiming in to confirm what Anne said (for proof and reference I
> attach a somewhat enhanced demo file we used to compare our doc.all
> cloaking and support to other implementations).
No problem, I believed Anne! No doubt.
> I didn't quite understand the comment about "treating assignment as
> 'detecting'" because we do no such thing.
The jaron is odd, but you do. A "detecting" use of document.all would be
if (document.all) { IE-only content here }
We found (see the links in https://bugzilla.mozilla.org/show_bug.cgi?id=259935
#c0 ) that content also did
d=document;
this.ie=(d.all);
and so assignment is "detecting" too, and does *not* detect the
document.all collection.
Opera does the same thing with a different value, false instead of
undefined, which is why I wrote "It's similar". It's almos the same in
effect, in this kind of assignment use-case.
>> Let me get this straight: the only cases where Opera evaluates
>> document.all to false are cases in ECMA-262 that apply the ToBoolean
>> internal helper. Otherwise it evaluates to a collection.
>
> While I haven't looked up ToBoolean in 262 now to confirm, this
> sounds exactly right.
>
> We seem to have gotten away without more magic, compatibility-wise.
> I looked through your Google code searches.
See the bug cited above and its links (the geocities one is probably
gone now; the ylib_dom.js one is still live and it does the "d" and
"this.ie" assignments shown above).
If Opera dodges bullets by other means, great. I was wondering,
though, if using undefined instead of false as the masquerade value
would not be even better, since undefined is falsy but also compares
== itself and null.
Thanks for the note -- my regards to Chris.
/be
Received on Tuesday, 13 October 2009 21:53:49 UTC