By KooiInc

2010-08-08 12:24:43 8 Comments

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'


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?


@Bekim Bacaj 2019-02-06 03:18:08

The question should sound:: "Do HTML Tags with provided IDs become globally accessible DOM Elements?"

The answer is YES!

That's how it was meant to work, and that's why IDs were introduced by W3C to begin with.: The ID of an HTML Tag in a parsed scripting environment becomes its corresponding DOM Element handle.

However, Netscape Mozilla refused to conform to (to them intruding) W3C and stubbornly kept using the deprecated Name attribute to create havoc and therefore break the Scripting functionality and the coding convenience brought in by the W3C's introduction of Unique IDs.

After the Netscape Navigator 4.7 fiasco their developers all went and infiltrated the W3C, whereas their associates were superseding the Web with wrong practices and misusing examples. Forcing the use and reuse of already deprecated Name attribute [!which was not meant to be unique] on par with ID attributes so that scripts that utilized ID handles for accessing particular DOM elements would simply break!

And break they did as they would also write and publish extensive coding lessons and examples [their browser would not recognize anyway] such as instead of to at least make it inefficient and give the browser more overhead in case it didn't simply break it at HTML domain by using the same token for the (now [1996-97], deprecated) Name and the standard ID attribute supplying it with the same token value.

They easily managed to convince the - back then - overwhelming army of ignorant code-writing amateurs that Names and IDs are practically the same, except that ID attribute is shorter and therefore byte-saving and more convenient to the coder than the ancient Name property. Which was of course a lie. Or - in their superseding published articles of HTML, convincing articles that you'll need to provide both Name and ID to your tags for them to be accessible by the Scripting engine.

Mosaic Killers [codenamed "Mozilla"] were so pissed they thought "if we go down, so should Internet".

The rising Microsoft - on the other hand - were so naive they thought they should keep the deprecated and marked for deletion Name property and treat it as if it was an ID that is a unique Identifier so that they wouldn't break the scripting functionality of old pages coded by Netscape trainees. They were deadly wrong...

And the returning of an array collection of ID conflicting elements was not a solution to this deliberate man-made problem either. Actually it defeated the whole purpose.

And this is the sole reason W3C turned ugly and gave us idiocies such as document.getElementById and the accompanying rococo goddamn annoying syntax of the sort... (...)

@TJ VanToll 2012-07-27 15:54:22

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 the id attribute for all elements are made available as properties of the global window object. These are known as named elements. Since window 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 an id of a DOM node, SURPRISE!

Additionally, despite being standardized there are still quite a few discrepancies in browser's implementations of named access.

  • IE incorrectly makes the value of the name attribute accessible for form elements (input, select, etc).
  • Gecko and Webkit incorrectly do NOT make <a> tags accessible via their name attribute.
  • Gecko incorrectly handles multiple named elements with the same name (it returns a reference to a single node instead of an array of references).

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 its id. If you need to get a reference to a node by its name attribute use document.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 -

@Jeremy Foster 2014-09-13 00:19:55

Just a note to the obvious caveat to the premise that "it should not be used". That is, "it should not be used UNLESS you happen to be a code cowboy." Code cowboys just go for it.

@Patrick Roberts 2015-06-28 05:30:23

@jeremyfoster unless "code cowboy" means someone who uses and propagates bad developer-unfriendly implementations, I strongly disagree.

@Jeremy Foster 2015-06-28 15:49:09

One mark of a good cowboy is that many disagree. But now I'm like the philosophical cowboy or something like that.

@Travis J 2015-10-28 23:14:15

More people should be using document.querySelectorAll and document.querySelector when accessing the DOM. +1 for the good suggestion of using that. Accessing elements by selector is definitely a more efficient process.

@Danny '365CSI' Engelman 2018-08-29 11:51:42

Link to TJ his site is broken...

@qff 2016-12-23 14:33:09

Yes, they do.

Tested in Chrome 55, Firefox 50, IE 11, IE Edge 14, and Safari 10
with the following example:

<!DOCTYPE html>
  <div id="im_not_particularly_happy_with_that">
    Hello World!
    im_not_particularly_happy_with_that.innerText = 'Hello Internet!';
  <!-- Looking at you W3 HTML5 spec group ಠ_ಠ -->

@ncmathsadist 2019-01-25 14:06:46

Also in Opera. However, I think the objection to this mechanism expressed on this page are very well taken.

@bobince 2010-08-08 13:03:05

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 of document.

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 the document or the window 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 or function 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 it var, 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 on window or as globals. Stick to document.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 the getElementById call to use a quick lookup anyway; all you get is problems when elements change id 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 on window 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 a name being used for ‘identifying’ purposes: that is, forms, images, anchors and a few others, but not other unrelated instances of a name attribute, like control-names in form input fields, parameter names in <param> or metadata type in <meta>. ‘Identifying’ names are the ones that should should be avoided in favour of id.

@KooiInc 2010-08-08 13:17:11

That's a clear answer, thanks. It wasn't my idea to omit document.getElementById (well, as a matter of fact I use xpath where possible to look up elements/elements properties nowadays). I stumbled upon this (bad) practice for named items and was curious as to where it came from. You answered that thouroughly enough; now we know why it also can be found in Chrome (webkit).

@Yahel 2011-08-17 13:33:20

One exception to "use of name should be avoided" is with <input>, where the name attribute plays a critical role in forming the key of key-value pairs for form submissions.

@Crescent Fresh 2011-08-17 14:04:49

FYI Firefox only does this when put into quirks mode.

@bobince 2011-08-17 14:53:15

@yahelc: that is exactly the distinction I'm making. “not other uses of name like control-names in form input fields...”

@mikemaccana 2013-01-09 15:28:52

Quick test to prove Chrome has the same issue:

@cde 2013-09-30 19:52:21

And as a note, Meta elements are not considered named elements for this purpose. How arbitrary...

@RobG 2013-11-04 22:37:49

@cde—the name attribute of a meta element doesn't identify the element, it identifies the purpose of the value of the content attribute.

@Volker E. 2014-05-01 20:44:46

“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.” Generally +1 for that rant. However, +the spec authors also cleaned some mess up, but sometimes it seems, they give in to personal bias, to opinions, to broad usage, etc.

@Farzher 2014-05-08 15:26:35

WHY!? Is there anything we can do to stop this madness? My functions got redefined by references to elements and it took an hour for me to debug. :(

@Dimitry K 2016-01-06 12:19:46

Can we have some TLDR for this post, and maybe update to 2016? Would it be like "Having 'named elements' exposed to global/window/document scope was a bad idea for the browsers to implement. And relying on this feature should be avoided. [TODO: what would be the advice for naming elements to avoid name clashes? eg. can I name my DIV#location?]'?

@Jonathan Marzullo 2016-03-15 16:22:24

the W3C link changed above for being standardized and is now:…

@T.J. Crowder 2016-10-30 17:45:40

@CrescentFresh: "Firefox only does this when put into quirks mode" Not any more, since it's been standardized.

@Jason Sperske 2017-05-19 17:13:48

I was curious to see the performance difference and I think this shows that it's dramatic, unless I'm missing something.

@johncip 2019-02-26 06:33:10

You've already linked the relevant section of the W3C spec, but the corresponding section of the HTML Living Standard is here:…

@Nick Craver 2010-08-08 12:29:09

You should stick to getElementById() in these cases, for example:


IE likes to mix elements with name and ID attributes in the global namespace, so best to be explicit about what you're trying to get.

Related Questions

Sponsored Content

18 Answered Questions

[SOLVED] Using global variables in a function

55 Answered Questions

[SOLVED] How do I check if an element is hidden in jQuery?

77 Answered Questions

[SOLVED] How do I detect a click outside an element?

  • 2008-09-30 13:17:12
  • Sergio del Amo
  • 1112117 View
  • 2284 Score
  • 77 Answer
  • Tags:   javascript jquery

79 Answered Questions

[SOLVED] How do I remove a particular element from an array in JavaScript?

  • 2011-04-23 22:17:18
  • Walker
  • 5841550 View
  • 7285 Score
  • 79 Answer
  • Tags:   javascript arrays

29 Answered Questions

[SOLVED] jQuery scroll to element

  • 2011-07-13 09:49:44
  • DiegoP.
  • 2260354 View
  • 2120 Score
  • 29 Answer
  • Tags:   javascript jquery

27 Answered Questions

[SOLVED] Remove all child elements of a DOM node in JavaScript

  • 2010-10-17 20:51:00
  • Polaris878
  • 700681 View
  • 730 Score
  • 27 Answer
  • Tags:   javascript dom

25 Answered Questions

[SOLVED] Retrieve the position (X,Y) of an HTML element

23 Answered Questions

[SOLVED] How to tell if a DOM element is visible in the current viewport?

14 Answered Questions

[SOLVED] How to move an element into another element?

  • 2009-08-14 20:14:45
  • Mark Richman
  • 1013900 View
  • 1568 Score
  • 14 Answer
  • Tags:   javascript jquery html

16 Answered Questions

[SOLVED] How do I find out which DOM element has the focus?

  • 2009-01-30 20:21:31
  • Tony Peterson
  • 596812 View
  • 1190 Score
  • 16 Answer
  • Tags:   javascript dom

Sponsored Content