Working on an idea for a simple HTMLElement wrapper I stumbled upon the following for Internet Explorer and Chrome:
For a given HTMLElement with ID in the DOM tree, it is possible to retrieve the div using its ID as the variable name. So for a div like
<div id="example">some text</div>
in Internet Explorer 8 and Chrome you can do:
alert(example.innerHTML); //=> 'some text'
or
alert(window['example'].innerHTML); //=> 'some text'
So, does this mean every element in the DOM tree is converted to a variable in the global namespace? And does it also mean one can use this as a replacement for the getElementById
method in these browsers?
What is supposed to happen is that ‘named elements’ are added as apparent properties of the
document
object. This is a really bad idea, as it allows element names to clash with real properties ofdocument
.IE made the situation worse by also adding named elements as properties of the
window
object. This is doubly bad in that now you have to avoid naming your elements after any member of either thedocument
or thewindow
object you (or any other library code in your project) might want to use.It also means that these elements are visible as global-like variables. Luckily in this case any real global
var
orfunction
declarations in your code shadow them, so you don't need to worry so much about naming here, but if you try to do an assignment to a global variable with a clashing name and you forget to declare itvar
, you'll get an error in IE as it tries to assign the value to the element itself.It's generally considered bad practice to omit
var
, as well as to rely on named elements being visible onwindow
or as globals. Stick todocument.getElementById
, which is more widely-supported and less ambiguous. You can write a trivial wrapper function with a shorter name if you don't like the typing. Either way, there's no point in using an id-to-element lookup cache, because browsers typically optimise thegetElementById
call to use a quick lookup anyway; all you get is problems when elements changeid
or are added/removed from the document.Opera copied IE, then WebKit joined in, and now both the previously-unstandardised practice of putting named elements on
document
properties, and the previously-IE-only practice of putting them onwindow
are being standardised by HTML5, whose approach is to document and standardise every terrible practice inflicted on us by browser authors, making them part of the web forever. So Firefox 4 will also support this.What are ‘named elements’? Anything with an
id
, and anything with aname
being used for ‘identifying’ purposes: that is, forms, images, anchors and a few others, but not other unrelated instances of aname
attribute, like control-names in form input fields, parameter names in<param>
or metadata type in<meta>
. ‘Identifying’name
s are the ones that should should be avoided in favour ofid
.Yes, they do.
Tested in Chrome 55, Firefox 50, IE 11, IE Edge 14, and Safari 10
with the following example:
http://jsbin.com/mahobinopa/edit?html,output
You should stick to
getElementById()
in these cases, for example:IE likes to mix elements with
name
andID
attributes in the global namespace, so best to be explicit about what you're trying to get.As mentioned in the earlier answer this behavior is known as named access on the window object. The value of the
name
attribute for some elements and the value of theid
attribute for all elements are made available as properties of the globalwindow
object. These are known as named elements. Sincewindow
is the global object in the browser, each named element will be accessible as a global variable.This was originally added by Internet Explorer and eventually was implemented by all other browsers simply for compatibility with sites that are dependent on this behavior. Interestingly, Gecko (Firefox's rendering engine) chose to implement this in quirks mode only, whereas other rendering engines left it on in standards mode.
However, as of Firefox 14, Firefox now supports named access on the
window
object in standards mode as well. Why did they change this? Turns out there's still a lot of sites that rely on this functionality in standards mode. Microsoft even released a marketing demo that did, preventing the demo from working in Firefox.Webkit has recently considered the opposite, relegating named access on the
window
object to quirks mode only. They decided against it by the same reasoning as Gecko.So… crazy as it seems this behavior is now technically safe to use in the latest version of all major browsers in standards mode. But while named access can seem somewhat convenient , it should not be used.
Why? A lot of the reasoning can be summed up in this article about why global variables are bad. Simply put, having a bunch of extra global variables leads to more bugs. Let's say you accidentally type the name of a
var
and happen to type anid
of a DOM node, SURPRISE!Additionally, despite being standardized there are still quite a few discrepancies in browser's implementations of named access.
name
attribute accessible for form elements (input, select, etc).<a>
tags accessible via theirname
attribute.And I'm sure there's more if you try using named access on edge cases.
As mentioned in other answers use
document.getElementById
to get a reference to a DOM node by itsid
. If you need to get a reference to a node by itsname
attribute usedocument.querySelectorAll
.Please, please do not propagate this problem by using named access in your site. So many web developers have wasted time trying to track down this magical behavior. We really need to take action and get rendering engines to turn named access off in standards mode. In the short term it will break some sites doing bad things, but in the long run it'll help move the web forward.
If you're interested I talk about this in more detail on my blog - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/.