- 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