Quiz: What is logged when the following markup is rendered?
<html>
<head></head>
<body>
<button id="bar">Button</button>
<script>
console.log(bar);
</script>
</body>
</html>
ReferenceError obviously, right? Wrong. All major browser rendering engines will log a reference to the <button> node. This includes Trident (IE), Gecko (Firefox), WebKit (Chrome, Safari, etc), and Presto (Opera).
Wait. What?
Ah, I get it, there’s no doctype on that markup. So this a quirks mode only thing then right? Wrong. As of Firefox 14 the latest version of all major browsers will produce the same result IN STANDARDS MODE.
<!DOCTYPE html>
<html>
<head></head>
<body>
<button id="bar">Button</button>
<script>
console.log(bar); //Reference to <button>, even in standards mode
</script>
</body>
</html>
So What’s Going On?
Believe it or not this is actually correct behavior per the HTML specification.
6.2.4 Named access on the Window object
The Window interface supports named properties. The supported property names at any moment consist of:
the value of the name content attribute for all a, applet, area, embed, form, frame, frameset, iframe, img, and object elements in the active document that have a name content attribute, and the value of the id content attribute of any HTML element in the active document with an id content attribute.
What this is saying is that the value of the name attribute of certain elements and the value of the id attribute of ALL elements are accessible via the window object in the browser. So, if you have a node <button id="foo"></button>, then window.foo will be resolved to a reference to the <button>. From this point forward I will refer to this behavior as named access.
How is This Standard Behavior?
This behavior is an old Internet Explorer feature. I can only imagine that it was intended to be a convenience for web developers that got sick of typing document.getElementById over and over again. (this is way before jQuery and other popular toolkits came to be). Regardless of the reasoning, IE shipped with this functionality and a whole lot of people utilized it.
Other rendering engines were faced with the difficult decision of implementing non-standard behavior or remaining incompatible with a slew of websites written specifically for Internet Explorer.
Gecko implemented this functionality but originally turned it on only in quirks mode. They recently took the extra step and turned named access on in standards mode with Firefox 14.
Webkit and Presto have had named access in standards mode for some time now. Webkit recently considered relegating this behavior to quirks mode, however, they decided on leaving it enabled in standards mode. Apparently there is still just too much stuff out there relying on this behavior to remove it in standards mode. Believe it or not Microsoft even shipped a marketing demo that directly referenced named DOM elements, preventing it from functioning in Gecko.
One of the main aims of the HTML5 specification is to standardize browser behavior, however quirky it might be. Therefore, this functionality made it into the specification.
Why is This Behavior Bad?
I’ve alluded to the fact that this behavior is bad, but I’ve haven’t gotten into details as to why.
There is a high potential for bugs to be introduced into the system
Let’s say you have some code that looks something like this:
<html>
<head></head>
<body>
<input type="text" id="choice"></button>
<script>
var choice = 'foo';
//Lots more JavaScript
doSomethingVeryComplicated(choice);
</script>
</body>
</html>
Since a global choice variable is being created, window.choice will resolve to the string foo and not a reference to the <input>. This is because the <input> reference is being shadowed by the variable declaration. This works the same way as a variable with the same name being declared in a nested function.
(function() {
var x = 2;
var y = function() {
var x = 3;
//Logs 3 instead of 2 because the value defined in the outer
//function is shadowed by the x defined in the inner function.
console.log(x);
};
y();
}());
This is all well and good. However, let’s say that during a refactor of this code the var choice = 'foo'; line is accidentally removed. Under normal circumstances this would cause a ReferenceError because window.choice would now be undefined. However, because there is a DOM node with an id of choice, that reference will now refer to the DOM node instead. This can easily lead to unexpected behavior.
The flip side of this situation is also true. If you have an element <div id="bar"></div> and use window.bar to refer to it, that code will break if you create JavaScript variable using var in the same scope (i.e. var bar = 2;).
Mistyping
Say you mistype the name of your variable and happen to type a named DOM element. SURPRISE!
Non-trivial cost for the browser to implement
In order for these named elements to be available, the browser has to create a list of all named elements and maintain it as the page changes. I can’t offer any specific metrics as to how much time and memory this takes, but there is a cost, especially on pages with a large number of named elements.
Named elements will be shadowed by properties natively defined on window.
If you were to go the route of using named access you’d have to be careful to avoid using named elements with values that are predefined on the window already.
For example you cannot refer to a <input id="location"> by window.location because that already resolves to an object with information about the URL of the current document.
There are a number of other property names on the window object that you could easily see being used to name a DOM element - event, history, name, self, status, and toolbar to name a few.
Browsers have inconsistent implementations.
Even though this is behavior is now standardized, there are still browser quirks in the way named access is implemented.
IE and Form Elements
IE will (incorrectly) make the name attribute of form elements available on the window object.
<!DOCTYPE html>
<html>
<head></head>
<body>
<input name="foo" />
<script>
//Logs a reference to the <input> in IE.
//ReferenceError in all other rendering engines.
console.log(foo);
</script>
</body>
</html>
Update: Microsoft’s Edge browser no longer exhibits this behavior. Also, this behavior is not present when the
<input>resides within a<form>element.
Name Attribute on Anchor Tags
Per the spec, <a> tags should be accessible on the window object via the value of their name attribute. However, this only works in IE and Opera.
<!DOCTYPE html>
<html>
<head></head>
<body>
<a name="foo"></a>
<script>
//Logs a reference to the <a> in IE and Opera.
//ReferenceError in Gecko and WebKit.
console.log(foo);
</script>
</body>
</html>
Multiple Named Attributes with the Same Value
…if elements has only one element, return that element and abort these steps.
Otherwise return an HTMLCollection rooted at the Document node, whose filter matches only named elements with the name name.
What this is staying is that when there are multiple named properties with the same name, the browser should return an array when that property is referenced (instead of a reference to a specific DOM node). As an example given this markup:
<!DOCTYPE html>
<html>
<head></head>
<body>
<input id="one">
<input id="one">
<script>
console.log(one);
</script>
</body>
</html>
…an array with references to the two <input> nodes should be logged per the spec. And it will be in all browsers except Firefox. Firefox 14 will simply log the first element.
Having two elements with the same id is invalid HTML, but the browser will still render it just fine. Even with the best of intentions these sorts of things do happen, especially in larger, dynamic applications.
More?
These are simply the bugs that I’ve ran into, I’m sure there are more. If you know of any let me know in the comments and I can update this list.
But won’t strict mode prevent this?
ECMAScript 5 strict mode prevents you assigning values to variables before they are declared. Therefore this…
(function() {
foo = 2;
}());
will execute just fine whereas this…
(function() {
'use strict';
foo = 2;
}());
…will produce a ReferenceError that foo is not defined. This is great, but it will not stop you from accessing named properties on the window object.
<div id="foo"></div>
<script>
(function() {
'use strict';
console.log(foo);
});
</script>
This will log a reference to the <div> in standards mode in the latest version of all modern browsers. Strict mode will only prevent you from assigning values to variables that have yet to be declared. If you’re simply using a variable then strict mode doesn’t protect you. Therefore, you’re not prevented from accessing name properties on the global window object.
What to do instead
Use document.getElementById to retrieve references to DOM nodes via their id attribute.
<button id="foo"></button>
<script>
document.getElementById('foo');
</script>
To get a reference to a DOM node via its name attribute you can use document.getElementsByName or document.querySelectorAll.
<a name="bar"></a>
<script>
document.getElementsByName('bar');
document.querySelectorAll('[name=bar]');
</script>
document.querySelectorAll is not safe to use in IE <= 8, but document.getElementsByName is safe to use in all browsers.
Conclusion
All major browsers now make named properties available on the global window object in standards mode. It’s important to know that browsers do this because you’ll likely run into this at some point. However, never purposely utilize this functionality. If you see others use it tell them to stop, ridicule them, do whatever it takes. Help move the web forward.
Update September 24th, 2012
Per comments from Rob W I’ve updated the following:
- I had incorrectly used “Syntax error” to describe the situation when an undeclared variable is referenced. I updated those to correctly use “ReferenceError”.
- I updated my last example to show that
document.getElementsByNameis a cross browser way of getting reference to DOM nodes by their name attribute.