Re: Global variables and id lookup for elements
To follow up, this issue is https://bugs.ecmascript.org/show_bug.cgi?id=78 On Jul 19, 2011, at 7:44 PM, Allen Wirfs-Brock wrote: On Jul 19, 2011, at 6:47 PM, Boris Zbarsky wrote: On 7/19/11 7:43 PM, Ian Hickson wrote: On Thu, 28 Apr 2011, Magnus Kristiansen wrote: Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707 Current browsers disagree about how to handlediv id=x/divscriptvar 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 Is this still something I should do, or did this get resolved using another solution? Unclear. For one thing, the ES5 spec on this has changed, and there is no public draft with the errata yet; they're only present in the form of e-mails. That makes it hard for me to say at this point whether the above claim is even true. That said, even if we ignore the behavior of var, that leaves open questions about what happens on assignment, etc. I do think Cameron has done a bunch of testing of this stuff recently, and there was a data table that summarized the results somewhere. You should probably just talk to him about it. There we two bugs in this regard in the original ES5 spec, one related to function declarations and the other related to var declarations. Functions were partially fixed in the ES5.1 specification but that fix still had a problem in that it did a GetProperty rather than a GetOwnProperty when check to see if a function has been declared on the global object. None of the corresponding fix for vars make it into the 5.1 spec. Both 5.1 corrections were described by me on the es5-discuss mailing list this past January. Those fixes will be included in the first Errata for ES5.1. The relevant message with the algorithm correction is https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003882.html Allen
Re: Global variables and id lookup for elements
On 7/19/11, Cameron McCormack c...@mcc.id.au wrote:
Ian Hickson:
Is this still something I should do, or did this get resolved using
another solution?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241
The proposed solution I made in the bug was to have the [[Get]] etc.
internal methods of Window handle the resolution order of window named
properties, rather than to use inheritance in the IDL to control the
order. I made that change to Web IDL, which would require you defining
which named properties are “resolved before prototype properties”, and
that’d be the frame names; the (possible quirks mode only) ID lookups
would be done last automatically, since Window isn’t [OverrideBuiltins].
That's different than the way Gecko does it, though.
In Gecko, window.frames === window, and so `window.frames['F']` ===
window['F'].
However element IDs that are resolved off window are resolved off a
special object off window's prototype chain [object Global Scope
Polluter]. GlobalScopePolluter is on window's prototype's prototype:
| ({}).toString.call(window.__proto__.__proto__)
[object Global Scope Polluter]
It is worth mentioning that window's prototype chain includes
GlobalScopePolluter both in quirks and in standards mode. When in
standards mode, element IDs are not resolved and in quirks mode, they
are resolved, but a script warning is issued.
I don't know if anybody cares about the details of this, but if it is
going to be standardized, then it is worth considering how various
browsers handle this legacy feature.
--
Garrett
Re: Global variables and id lookup for elements
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/divscriptvar 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/divscriptvar 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.
Re: Global variables and id lookup for elements
Ian Hickson: Is this still something I should do, or did this get resolved using another solution? http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 The proposed solution I made in the bug was to have the [[Get]] etc. internal methods of Window handle the resolution order of window named properties, rather than to use inheritance in the IDL to control the order. I made that change to Web IDL, which would require you defining which named properties are “resolved before prototype properties”, and that’d be the frame names; the (possible quirks mode only) ID lookups would be done last automatically, since Window isn’t [OverrideBuiltins]. However, Tony Ross on the bug there says he would rather an even simpler solution that resoles all frame names and ID lookups after everything else (i.e. like normal non-[OverrideBuiltins] interfaces). I haven’t made any spec changes since then. It would be good to get more input on the bug. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Global variables and id lookup for elements
On Wed, 20 Jul 2011, Cameron McCormack wrote: Ian Hickson: Is this still something I should do, or did this get resolved using another solution? http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 The proposed solution I made in the bug was to have the [[Get]] etc. internal methods of Window handle the resolution order of window named properties, rather than to use inheritance in the IDL to control the order. I made that change to Web IDL, which would require you defining which named properties are “resolved before prototype properties”, and that’d be the frame names; the (possible quirks mode only) ID lookups would be done last automatically, since Window isn’t [OverrideBuiltins]. However, Tony Ross on the bug there says he would rather an even simpler solution that resoles all frame names and ID lookups after everything else (i.e. like normal non-[OverrideBuiltins] interfaces). I haven’t made any spec changes since then. It would be good to get more input on the bug. Ok, thanks. I have no opinion on what exactly we should do here. Since it's assigned to you, I'll let you make the call; if any changes should be necessary in the HTML spec (e.g. removing the [ReplaceableNamedProperties] annotation or changing the prose for the getter) please describe the needed change and reassign the bug to me (in an open state). Thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Global variables and id lookup for elements
On Jul 19, 2011, at 6:47 PM, Boris Zbarsky wrote: On 7/19/11 7:43 PM, Ian Hickson wrote: On Thu, 28 Apr 2011, Magnus Kristiansen wrote: Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707 Current browsers disagree about how to handlediv id=x/divscriptvar 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 Is this still something I should do, or did this get resolved using another solution? Unclear. For one thing, the ES5 spec on this has changed, and there is no public draft with the errata yet; they're only present in the form of e-mails. That makes it hard for me to say at this point whether the above claim is even true. That said, even if we ignore the behavior of var, that leaves open questions about what happens on assignment, etc. I do think Cameron has done a bunch of testing of this stuff recently, and there was a data table that summarized the results somewhere. You should probably just talk to him about it. There we two bugs in this regard in the original ES5 spec, one related to function declarations and the other related to var declarations. Functions were partially fixed in the ES5.1 specification but that fix still had a problem in that it did a GetProperty rather than a GetOwnProperty when check to see if a function has been declared on the global object. None of the corresponding fix for vars make it into the 5.1 spec. Both 5.1 corrections were described by me on the es5-discuss mailing list this past January. Those fixes will be included in the first Errata for ES5.1. The relevant message with the algorithm correction is https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003882.html Allen
Global variables and id lookup for elements
Hey folks, Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707 Current browsers disagree about how to handle div id=x/divscriptvar 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 -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: Global variables and id lookup for elements
On 4/28/11 4:31 PM, Magnus Kristiansen wrote: Current browsers disagree about how to handle div id=x/divscriptvar 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. -Boris
Re: Global variables and id lookup for elements
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 {
...
};
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Global variables and id lookup for elements
On 4/28/11, Boris Zbarsky bzbar...@mit.edu wrote: 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. That is correct. Because it is available in quirks mode only, GlobalScopePolluter addresses legacy code designed to run in IE without burdening other scripts with the problematic complexities it causes. -- Garrett
