umiruq
Last Updated: November 06, 2018
·
4.99K
· teddy

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).

12 Responses
Add your response

9625

What about a 'fancy hack' like this (didn't test if it works):

var element = rampus || document.getElementById('rampus')

over 1 year ago ·
9626

What about not using global variables? Never.

over 1 year ago ·
9633

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.

over 1 year ago ·
9651
9663

While this may work, it is so terrible for code maintenance that I would never consider it.

over 1 year ago ·
9682

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.

over 1 year ago ·
9683

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.

over 1 year ago ·
9694

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.

over 1 year ago ·
9696

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.

over 1 year ago ·
9704

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');.

over 1 year ago ·
9735

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')

over 1 year ago ·
9918

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.

over 1 year ago ·