- 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