- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 19 Jul 2011 23:43:11 +0000 (UTC)
- To: Magnus Kristiansen <magnusrk+w3c@pvv.org>, Boris Zbarsky <bzbarsky@MIT.EDU>, Cameron McCormack <cam@mcc.id.au>
- cc: public-webapps@w3.org
On Thu, 28 Apr 2011, Magnus Kristiansen wrote: > > Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707 > > Current browsers disagree about how to handle <div > id=x></div><script>var x;</script>. Webkit browsers leave x pointing to > the div, whereas IE, Firefox and Opera make x undefined [1]. (There is > content that depends on x being undefined, but I don't have any links > handy right now.) > > My reading of the relevant specs (es5 section 10, WebIDL 4.5.3, HTML > 6.2.4) supports the Webkit behavior. To summarize, a property x is > defined on the global object pointing to the element before the script > block, and when the script block is parsed for variable declarations > there's already an x defined and therefore the variable is not > initialized to undefined. I therefore propose a spec change is in order. > > jgraham summarized the wanted behavior neatly as "id lookup should > happen after all other property resolution". Conceptually I think this > is like saying that the global environment actually has an outer > environment, and this outer environment contains the properties for > element lookups (which are currently defined on the global object). > Another proposal was to say that properties for element lookup are > special and should get overwritten in 10.8.c. Other, better options may > also exist. > > Open question: Should this be defined directly in HTML, or should WebIDL > define it and let HTML annotate Window to enable the necessary > exceptional behavior? My initial take was that since both id lookup and > window=global is defined in HTML it would fit best there, but it also > makes sense to contain finicky DOM-ES interactions to WebIDL. > > [1] http://code.google.com/p/chromium/issues/detail?id=80591 On Thu, 28 Apr 2011, Boris Zbarsky wrote: > On 4/28/11 4:31 PM, Magnus Kristiansen wrote: > > Current browsers disagree about how to handle <div > > id=x></div><script>var x;</script>. Webkit browsers leave x pointing > > to the div, whereas IE, Firefox and Opera make x undefined [1]. (There > > is content that depends on x being undefined, but I don't have any > > links handy right now.) > > > > My reading of the relevant specs (es5 section 10, WebIDL 4.5.3, HTML > > 6.2.4) supports the Webkit behavior. To summarize, a property x is > > defined on the global object pointing to the element before the script > > block, and when the script block is parsed for variable declarations > > there's already an x defined and therefore the variable is not > > initialized to undefined. I therefore propose a spec change is in > > order. > > I believe this is correct. For what it's worth, I discussed this with > Cameron recently, and he felt that this is something that should just be > defined as a one-off in the spec defining Window, not in WebIDL itself. > > That is, Window should not be using a name getter. > > > jgraham summarized the wanted behavior neatly as "id lookup should > > happen after all other property resolution". Conceptually I think this > > is like saying that the global environment actually has an outer > > environment, and this outer environment contains the properties for > > element lookups (which are currently defined on the global object). > > Another proposal was to say that properties for element lookup are > > special and should get overwritten in 10.8.c. Other, better options > > may also exist. > > For what it's worth, the way Gecko implements this is by inserting an > object into the prototype chain of the Window that handles these > property gets. This means that |var| (which defines a prop on the > Window itself) will always shadow the named props, which is the behavior > you observe. > > There's some complexity due to the fact that the properties should only > exist on that prototype if they're not anywhere else on the proto chain, > but that's already there in the non-OverrideBuiltins name getter case. > > > Open question: Should this be defined directly in HTML, or should > > WebIDL define it and let HTML annotate Window to enable the necessary > > exceptional behavior? > > I think I agree with Cameron that it should be defined in HTML (or > whatever spec defines Window). > > > My initial take was that since both id lookup and window=global is > > defined in HTML it would fit best there, but it also makes sense to > > contain finicky DOM-ES interactions to WebIDL. > > Reusable ones, yes. I don't think anyone is proposing this behavior for > any other object, so it wouldn't be reusable anyway. On Fri, 29 Apr 2011, Cameron McCormack wrote: > Boris Zbarsky: > > For what it's worth, the way Gecko implements this is by inserting an > > object into the prototype chain of the Window that handles these > > property gets. This means that |var| (which defines a prop on the > > Window itself) will always shadow the named props, which is the > > behavior you observe. > > If we solve the problem in this way, with an extra object in the > prototype chain, then this could be defined in HTML without any special > prose. > > [NoInterfaceObject] > interface WindowNames { > getter any (in DOMString name); > }; > > interface Window : WindowNames { > ... > }; Is this still something I should do, or did this get resolved using another solution? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 19 July 2011 23:43:37 UTC