Is there a spec that the id of elements should be made global variable?_问答_开发者

If I have a <div id='a'> in Chrome then in javascript I can do a.stuff() (it's like as if a is a global variable).

However this does not work with FireFox - I will need to use document.getElementById('a').

What is the correct behaviour here? (according to W3 specs that is)

开发者_Go百科

Also I'm interested in how will Chrome resolve the ambiguity if I have a div with id a yet have a global variable called a too in my script. Is the behavior going to be random and whacky?

And how would an element with id consisting of hyphens ("-"), colons (":"), and periods (".") be translated (ok i know they can be accessed with document.getElementById but how will the browser translate it into the global variable that was representing them)

It depends on which spec you read. :)

This behavior is not described by the HTML4 specification (c.f., http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-id and http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-name). However, it was introduced by Internet Explorer and then copied in other major browsers for compatibility. FireFox also displays this behavior, but only in quirks mode (and even then its implementation seems buggy).

The WHATWG HTML spec currently requires this behavior (a bug report requesting it be removed was closed WONTFIX).

Regardless of spec compliance, using the global namespace (i.e., window) for application code is generally considered bad behavior. Consider referencing element IDs using document.getElementById() or jQuery convenience methods (e.g., $("#a")) and using function-scoped variables to avoid introducing new variables into the global namespace.

There is a longer discussion of this behavior on the WHATWG mailing list.

Since very early days, IE has created global variables that reference elements by their name or id attribute value. This was never a good idea, but was copied by other browsers in order to be compatible with sites created for IE.

It is a bad idea and should not be copied or used.

Edit

To answer your extra questions:

...how will Chrome resolve the ambiguity if i have a div with id a yet have a global variable called a too in my script.

In IE (which introduced this behaviour) if a global variable is declared with the same name as an element id or name, it will take precedence. However, undeclared globals don't work that way. It shoudn't take much to test that in Chrome (I have but I'm not going to give you the answer).

And how would an element with id consisting of hyphens ("-"), colons (":"), and periods (".") be translated (ok i know they can be accessed with document.getElementById but how will the browser translate it into the global variable that was representing them)

Exactly the same as any object property name that is not a valid identifier - square bracket notation (i.e. window['name-or-id']).

Technically, this question is opinion, but it's a good question.

IE does this as well and it has caused headaches for some.

The rules for naming variables in JavaScript and IDs in HTML are different. I can't see how this is a good thing.

For instance, on this page there is an element with an ID of "notify-container". That's not a valid JavaScript name at all.

Also, when are these names bound? If an inline script declares a variable and then the element appears later, which has precedence?

It's cannot be made consistent.

The worst thing about using elements this way is that they could break at any time if a new API is introduced that has the same name in the global scope.

For example, if you had this prior to the addition of the Performance API

<p id="performance"></p>
<script>
    performance.innerHTML = "You're doing great"
</script>

Then that piece of code would've stopped working now in recent browsers that implemented the Performance API as a global performance object was added.

I think document.getElementById is supported by most browsers so far.. Its better and safe using this one..