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></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.

-Boris

Received on Thursday, 28 April 2011 21:02:34 UTC