JavaScript getElementById Not Required
Okay, so this can't be considered best practices and it certainly didn't work on IE8, but getElementById is not required for grabbing DOM elements. Try it.
Consider this snippet:
<body>
<div id="rumpus"></div>
</body>
<script type="text/javascript">
rumpus.innerHTML = "roo";
</script>Surely, rumpus is undefined and will throw an error when trying to access a method within it. But nope. When the page renders, all you see is "roo" and no errors in the console.
So what happens when there is a variable defined the same as the ID? JavaScript will consider the var, even if defined lower, as the variable to find and will ignore the DOM.
<body>
<div id="rumpus"></div>
</body>
<script type="text/javascript">
rumpus.innerHTML = "roo";
var rumpus;
</script>
Uncaught TypeError: Cannot set property 'innerHTML' of undefined I have tried this in IE10, Chrome 29, Firefox 24, and Safari 5 for Windows, all resulting in success. Not so with IE8. Again, this shouldn't be used as a best practice, but may explain why you're getting weird results (like I was) when you're code cannot access the variable you think it would be (like mine was).
Written by Teddy Garland
Related protips
12 Responses
What about a 'fancy hack' like this (didn't test if it works):
var element = rampus || document.getElementById('rampus')
What about not using global variables? Never.
variable hoisting is what causes the second example to work differently. Here's a pretty good read about it Javascript Variable Scoping and Hoisting
TL:DR
Function declarations and variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
To bad it isn't faster :)
http://jsperf.com/to-use-or-not-to-use-getelementbyid-for-performance
While this may work, it is so terrible for code maintenance that I would never consider it.
Instead of using the "id" attribute, you could have used the "name" attribute on some elements, e.g. img, form, etc. But not iframe because the "name" will specify the name of its contentWindow.
I ran into this same "feature": http://joe-on-software.blogspot.com/2012/12/html-ids-and-javascript.html
As far as I can tell, it works on all browsers and is very easy to clobber.
I also found the issue when I wrote a scroll-UI.js (which use to change the default scroll bar style base on javascript) a month ago.
I think it might add a horrible maintenance confusion, as you'll be looking for "var" keyword to know if something is a variable (or reference) or a variable, i think it adds a layer of complication that might be not necessary. And as some guys has said, it should be really slow as your using Globals as your scope, which is not a good thing.
At first sight this is enticing but when you think about it you'll see that anyone doing maintenance on these projects would be extremely confused looking for definitions of these magical variables. I'll stay away from this for now. If that reason alone isn't enough then the lack of support in IE8 (10% of the consumer market) should be unless you plan on hacking every variable with var element = rampus || document.getElementById('rampus');.
This is not a javascript thing, this is a browser thing. Some/most browsers assign DOM elements to variables they create and name with the elements' IDs.
This is a good tool for quick debugging from the dev tools console but it shouldn't be used in JS code.
You can also get the jQuery object by doing $(rampus) instead of $('#rampus')
I get this is "nifty" to some extent - but i can't for the life of me think why anyone would want to use something like this in production? At best it just makes code harder to follow and at worst it'll end up with variables conflicting and cause all sorts of headaches.
