13

Possible Duplicate:
IE/Chrome: are DOM tree elements global variables here?

I just stumbled upon an unexpected but useful behavior in the browser: It creates a variable for every element that has an ID in my html code. So when I have:

<div id="ohlala"> ... </div>

the browser seem to run this code behind the scene:

var ohlala = document.getElementById("ohlala");

so I can easily change the text of that element by:

ohlala.innerHTML="test"

Try it online: http://jsfiddle.net/Facby/ The question is: why would I need to write the document.getElementById() bit myself? How portable is that code? I tried in Opera, FireFox and Chrome and it works! Can I rely on this functionality? Does the browser always create variables for every element with id? In that case I have to be more careful about the names that are used in my javascript code not to conflict with similar ids from the HTML, right?

Community
  • 1
  • 1
AlexStack
  • 16,766
  • 21
  • 72
  • 104
  • That's common, but AFAIK not standard. It started all in Internet Explorer, as you may imagine. IIRC older Firefox versions don't support it, and I don't know anything about it for mobile browsers. – MaxArt Sep 20 '12 at 10:13
  • 4
    Also, you have a lot of pre-existing properties on the `window` object, defining elements with ids matching those properties won't replace them on the `window` object and you will find yourself in a situation where you either have to avoid certain ids, or use `getElementById` _only_ for certain ids. – lanzz Sep 20 '12 at 10:18
  • 1
    it will be problem in multiple forms .where we sometime use document.form[].element – Ashish Gupta Sep 20 '12 at 10:19
  • I checked it for Firefox 3.6 and it doesn't work. By the way, did you test if it works when you dynamically append elements to the DOM? It's ok in IE and Chrome, don't know about the others. – MaxArt Sep 20 '12 at 10:26
  • 4
    DUPLICATE OF http://stackoverflow.com/q/3434278/1085285 http://stackoverflow.com/q/7826737/1085285 – Ashish Gupta Sep 20 '12 at 10:26
  • 2
    the problem (except that this is very bad practice) is that you will mix up variables like @lanzz said. how do you know what `ohlaha` was? you will have to guess – Martin Trenker Sep 20 '12 at 10:27
  • yeah for the sake of code readability it's better to avoid that. – AlexStack Sep 21 '12 at 08:41

1 Answers1

5

When creating elements with IDs, the "window" object receives the specific attributes, that's why you can use variables directly, this behavior is deprecated and usually is wrote like this: window.ohlala.innerHTML = "...", this behavior is conserved by the browsers for compatibility with some older code on websites, but it is not recommended to use it in modern websites, always use .getElementById() method, this method is part of a W3C Standard, and you can use it in all modern browsers, in some very old browser versions and < IE7 it will not work. Learn more about DOM (Document Object Model) here: https://developer.mozilla.org/en-US/docs/DOM

micnic
  • 10,915
  • 5
  • 44
  • 55
  • Which specific W3C standard would that be? – lanzz Sep 20 '12 at 10:18
  • Can you point to the document, where this behavior is standardized? – Sirko Sep 20 '12 at 10:19
  • You can find all W3C standards here: http://w3c.org getElementById was introduced in DOM Level 1 for HTML documents and moved to all documents in DOM Level 2: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId – micnic Sep 20 '12 at 10:24
  • 3
    @micnic You noticed that the question did not concern `document.getElementById()`, but the implicit generation of a variable in the dom by the browser WITHOUT having to call `document.getElementById()`? – Sirko Sep 20 '12 at 10:25
  • @micnic Ok, I think you misunderstood the question. Feel free to delete your answer... – MaxArt Sep 20 '12 at 10:27
  • @MaxArt I'm not a Windows user and I don't know for sure the versions were it doesn't work in IE, IE6 doesn't support it 100%. – micnic Sep 20 '12 at 10:28
  • @MaxArt, I will improuve my answer :) – micnic Sep 20 '12 at 10:29
  • @micnic IE6 has an odd bug with `getElementById` that returns elements with the matching `name` property too, instead of `id` only, but somehow it *is* supported. Also, improving the answer will be good, but I can't imagine how. Surprise me :) – MaxArt Sep 20 '12 at 10:30
  • I looked at the document, but it doesn't mention this behavior: the browser is creating a variable for every named element automatically. – AlexStack Sep 20 '12 at 10:42
  • @AlexStack, I'm very sorry, I have misunderstood your question, I edited my answer, `window.newVar` is the same `newVar` that's why you can access it in global context, but this is a deprecated behavior – micnic Sep 20 '12 at 10:49
  • @micnic This behavior is now a part of HTML5 spec:http://dev.w3.org/html5/spec/single-page.html#named-access-on-the-window-object It is called "Named access on the Window object": http://dev.w3.org/html5/spec/single-page.html#dom-document-nameditem – AlexStack Sep 20 '12 at 10:57
  • @AlexStack I'd still advise agains relying on it, as the standards document you have referred explicitly warns that "Browser vendors are considering limiting this behaviour to quirks mode" – lanzz Sep 20 '12 at 11:04
  • @AlexStack Read carefully, that's not the same thing. The behaviour you were referring to is about *generic* DOM elements that create `window` properties identified by their `id`s. The link you've given deals with properties on the `document` object that matches some corrisponding 'named' items (explained some lines after that). – MaxArt Sep 20 '12 at 15:57