Develop Reference

Referring to element without document [duplicate]

This question already has answers here:
Do DOM tree elements with IDs become global properties?
(5 answers)
Closed 5 years ago.
Just today after a couple of years of javascript programming I came across something that left me startled. Browsers create objects for every element with an id. The name of the object will match the id.
So if you have:
<div id ="box"></div>
You can do:
alert(box); //[object HTMLDivElement]
Without first assigning anything to that variable. See the demo.
This for some reason seems to be in the standards even though it can break the code in some cases. There is an open bug to end this behavior but I'm more interested in getting rid of it now.
Do you guys know if there is a way to disable this (strict mode maybe)? Am I giving this too much importance? Because it certainly seems like a bad idea. (It was introduced by IE to give you a hint).
Update: It seems FF only does this in quirks mode. Other browsers like IE6+ and Chrome do it right off the bat.

ECMAScript 5 strict should help with this as you cannot use undeclared variables. I'm not sure which browsers currently support strict mode but I know Firefox 4 does.
The HTML spec you linked mentions a proposal to reduce pollution of the global scope by limiting this behavior to quirks-only.
I don't know if this feature is in the original spec but I do expect it to be removed, prohibited or otherwise nullified in subsequent versions of ECMAScript. ES6 will be based on ES5 strict.
JavaScript has many features that make it easier to use for beginners and novices, I suspect this is one such feature. If you're a professional and you want quality code use "use strict"; and always JSLint your code. If you use these guidelines this feature should never bother you.
Here is a useful video about ES5 courtesy of YUI Theater (it's already 2 years old though, but still relevant currently as there is no ES6 yet).

I don't think this is much of a big deal. It seems messy especially to those of us who think about global namespace pollution and conflicts, but in practice it doesn't really cause a problem.
If you declare your own global variable, it will just override anything the browser created for you so there's not really any conflict. The only place I could see it potentially causing a problem is if you were testing for the existence of a global declaration and an "auto" global based on an object ID got in the way of that and confused you.
In practice, I've never seen this to be a problem. But, I'd agree it seems like something they should get rid of or allow you to turn off.

Yes most browsers do this but then again like you said some don't (firefox) so don't count on it. It's also easy to overwrite these variables in js, I can imagine something like container might be overwritten right of the bat by someone using that variable without declaring it first.
There is no way to turn this of in chrome afaik but even then it might be a hassle to figure this out and fix it for all browsers.
Don't give it too much importance, but beware of it. This is one of those reasons why you would evade the global scope for variables.
For the sake of completion, these browsers definitly do it by default: Chrome, IE9 & compat, Opera
Update: Future versions of ECMAScript might include an option of some sort since yes discussion is going on, but that will not fix the 'problem' in older browsers.

I don't think there's a way to disable it, but you don't need to put much importance to it. If you are afraid of unpredictable bugs, you could avoid them by using JSHint or JSLint. They will help you avoid mistakes. For example, they will warn you if you use an undeclared variable.

The problem here is that the global scope has objects defined in it at runtime by the browser, and you would like to prevent these definitions from interfering with your code. I'm not aware of a way to turn off this behaviour, but I do have two workarounds for you:
1) As suggested in the article you linked to, you can work around this by ensuring that you define each variable before you use it. I would achieve this by running my code through JSLint, which warns about this sort of thing (in addition to a bunch of other common errors).
2) However, since it's possible to forget to run your code through JSLint, you might prefer a step in the tool chain that you can't forget. In that case, have a look at CoffeeScript - it's a langauge very similar to javascript that you compile into javascript before use, and it will insert the correct var definitions for you. In fact, I suspect that you can't write code that relies on the automatic element variable creation using CoffeeScript.

This is what I've been able to come up with to remove global variables that are automatically created for DOM objects with an ID value:
function clearElementGlobals() {
function clearItem(iden, item) {
if (iden && window[iden] && (window[iden] === item)) {
window[iden] = undefined;
}
}
var list = document.getElementsByTagName("*");
for (var i = 0, len = list.length; i < len; i++) {
var item = list[i];
clearItem(item.id, item);
clearItem(item.name, item);
}
}
This gets a list of all objects in the page. It loops through looking for ones with an id value and when there's an id value and a global variable exists for it and that global variable points to that DOM object, that global variable is set to undefined. As it turns out browsers also do this same auto-global for some types of tags with a name attribute (like form elements) so we clear those too.
Of course, this code can't know whether your own code makes a global variable with the same name as the id so it would obviously be best to either not do that in your own code or call this function before your global variables are initialized.
Unfortunately, you cannot delete global variables in javascript so setting it to undefined is about the best that can be done.
FYI, I tried doing this the other way around where you enumerate global variables looking for variables that are an instance of HTMLElement and that have a name that matches the id of the element they point to, but I couldn't find a reliable way to enumerate global variables. In Chrome, you can't enumerate them on the window object even though you can access them through the window object. So, I had to go the other way around by getting all DOM objects with an id and looking for globals that match them.
FYI, you asked about strict mode in your question. strict mode only applies to a given scope of code so there would not be any way to cause it to affect the way the global namespace was set up. To affect something like this, it would have to be something at the document level before the document was parsed like a DOCTYPE option or something like that.
Caveats with this function.
Run it before you create any of your own globals or don't create any of your own globals with the same name as the ID or name attribute that also point to that DOM object.
This is a one-time shot, not continuous. If you dynamically create new DOM objects, you would have to rerun this function to clear any new globals that might have been made from the new DOM objects.
The globals are set to undefined which is slightly different than if they were never there in the first place. I can't think of a programming case where it would really matter, but it isn't identical. Unfortunately, you can't delete global variables.

Since when and why dom id names are automatically defined as objects in js api [duplicate]

If I have a <div id='a'> in Chrome then in javascript I can do a.stuff() (it's like as if a is a global variable).
However this does not work with FireFox - I will need to use document.getElementById('a').
What is the correct behaviour here? (according to W3 specs that is)
Also I'm interested in how will Chrome resolve the ambiguity if I have a div with id a yet have a global variable called a too in my script. Is the behavior going to be random and whacky?
And how would an element with id consisting of hyphens ("-"), colons (":"), and periods (".") be translated (ok i know they can be accessed with document.getElementById but how will the browser translate it into the global variable that was representing them)

It depends on which spec you read. :)
This behavior is not described by the HTML4 specification (c.f., http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-id and http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-name). However, it was introduced by Internet Explorer and then copied in other major browsers for compatibility. FireFox also displays this behavior, but only in quirks mode (and even then its implementation seems buggy).
The WHATWG HTML spec currently requires this behavior (a bug report requesting it be removed was closed WONTFIX).
Regardless of spec compliance, using the global namespace (i.e., window) for application code is generally considered bad behavior. Consider referencing element IDs using document.getElementById() or jQuery convenience methods (e.g., $("#a")) and using function-scoped variables to avoid introducing new variables into the global namespace.
There is a longer discussion of this behavior on the WHATWG mailing list.

Since very early days, IE has created global variables that reference elements by their name or id attribute value. This was never a good idea, but was copied by other browsers in order to be compatible with sites created for IE.
It is a bad idea and should not be copied or used.
Edit
To answer your extra questions:
...how will Chrome resolve the
ambiguity if i have a div with id a
yet have a global variable called a
too in my script.
In IE (which introduced this behaviour) if a global variable is declared with the same name as an element id or name, it will take precedence. However, undeclared globals don't work that way. It shoudn't take much to test that in Chrome (I have but I'm not going to give you the answer).
And how would an element with id
consisting of hyphens ("-"), colons
(":"), and periods (".") be translated
(ok i know they can be accessed with
document.getElementById but how will
the browser translate it into the
global variable that was representing
them)
Exactly the same as any object property name that is not a valid identifier - square bracket notation (i.e. window['name-or-id']).

Technically, this question is opinion, but it's a good question.
IE does this as well and it has caused headaches for some.
The rules for naming variables in JavaScript and IDs in HTML are different. I can't see how this is a good thing.
For instance, on this page there is an element with an ID of "notify-container". That's not a valid JavaScript name at all.
Also, when are these names bound? If an inline script declares a variable and then the element appears later, which has precedence?
It's cannot be made consistent.

The worst thing about using elements this way is that they could break at any time if a new API is introduced that has the same name in the global scope.
For example, if you had this prior to the addition of the Performance API
<p id="performance"></p>
<script>
performance.innerHTML = "You're doing great"
</script>
Then that piece of code would've stopped working now in recent browsers that implemented the Performance API as a global performance object was added.

I think document.getElementById is supported by most browsers so far.. Its better and safe using this one..

Why is it bad practice to use implicit id references in javascript?

I have seen and avoided code like this:
<div id="myDiv" onClick="alert('hi!');">Div</div>
<script>
myDiv.click(); // <-- this bit seems wrong
</script>
It just seems wrong to me that I should refer to the node by it's id alone without explicitly assigning it to a variable first. Like this:
var myDiv = document.getElementById('myDiv');
Is there a good reason why we shouldn't use code like in the first example or am I just superstitious?

It's bad practice to use the identifiers from the page without specifying where they come from.
The identifiers are "magically" created as properties in the document object. If you use those, it's not clearly apperent how they got there in the first place. If you rename the element, the same Javascript code now creates a global variable instead, and it's hard to see by looking at the code what it was supposed to do, and why it's not working any more.
Also there is a risk for conflicts. If you create a global variable with the same name as the element id, then it will shadow the element and you can no longer reach it.
By using getElementById the code clearly says that there should be an element with that id in the page, and it also only looks for an element so the risk for naming conflicts is less.

Thanks to Bergi and Pete for links to useful information on this topic.
From these I have gleaned there are few main reasons why this is bad practice:
It's not supported in all browsers (although with html5 adopting implicit references this approach this may not be an issue going forward).
Namespace collision - the reference is put as a property on this window object. If a window property with a name the same as the id exists it may not be assigned.
Due to point 2, your code could break unexpectedly if a browser introduces a property with the same name as one of your ids.

First of all, it is a bad practice since the maintenance of such code will be very difficult, consider that the script is not located next to the element or even not in the same file.
Moreover, using ids in general is not recommended when your HTML page/app grows. The id attribute must remains unique and you may find it hard to follow it

Why is it bad to make elements global variables in Javascript?

I've heard that it's not a good idea to make elements global in JavaScript. I don't understand why. Is it something IE can't handle?
For example:
div = getElementById('topbar');

I don't think that's an implementation issue, but more a good vs bad practice issue. Usually global * is bad practice and should be avoided (global variables and so on) since you never really know how the scope of the project will evolve and how your file will be included.
I'm not a big JS freak so I won't be able to give you the specifics on exactly why JS events are bad but Christian Heilmann talks about JS best practices here, you could take a look. Also try googling "JS best practices"
Edit: Wikipedia about global variables, that could also apply to your problem :
[global variables] are usually
considered bad practice precisely
because of their nonlocality: a global
variable can potentially be modified
from anywhere, (unless they reside in
protected memory) and any part of the
program may depend on it. A global
variable therefore has an unlimited
potential for creating mutual
dependencies, and adding mutual
dependencies increases complexity. See
Action at a distance. However, in a
few cases, global variables can be
suitable for use. For example, they
can be used to avoid having to pass
frequently-used variables continuously
throughout several functions.
via http://en.wikipedia.org/wiki/Global_variable

Is it something IE can't handle?
No it is not an IE thing. You can never assume that your code will be the only script used in the document. So it is important that you make sure your code does not have global function or variable names that other scripts can override.
Refer to Play Well With Others for examples.

I assume by "events" you mean the event-handling JavaScript (functions).
In general, it's bad to use more than one global variable in JS. (It's impossible not to use at least one if you're storing any data for future use.) That's because it runs into the same problem as all namespacing tries to solve - what if you wrote a method doSomething() and someone else wrote a method called doSomething()?
The best way to get around this is to make a global variable that is an object to hold all of your data and functions. For example:
var MyStuff = {};
MyStuff.counter = 0;
MyStuff.eventHandler = function() { ... };
MyStuff.doSomething = function() { ... };
// Later, when you want to call doSomething()...
MyStuff.doSomething();
This way, you're minimally polluting the global namespace; you only need worry that someone else uses your global variable.
Of course, none of this is a problem if your code will never play with anyone else's... but this sort of thinking will bite you in the ass later if you ever do end up using someone else's code. As long as everyone plays nice in terms of JS global names, all code can get along.

There shouldn't be any problem using global variables in your code as long as you are wrapping them inside a uniqe namespase/object (to avoid collision with scripts that are not yours)
the main adventage of using global variable in javascript derives from the fact that javascript is not a strong type language. there for, if you pass somes complex objects as arguments to a function, you will probebly lose all the intellisence for those objects (inside the function scope.)
while using global objects insteads, will preserve that intellisence.
I personally find that very usfull and it certainly have place in my code.
(of course, one should alwayse make the right balance between locales and globals variables)

Why isn't it a must to declare a variable in Javascript before using it?

In Javascript we don't have to declare a variable with var keyword before using it. We can straight away do things like myCount = 12; or myStr = "Hello"; (where myCount, myStr are not declared before). Any such usage, declares and initializes the variables in the 'global' scope.
What could be the reasons for providing this feature? And is it a good standard at all?
UPDATE: My question is not what the differences are between 'using a variable without declaring' and 'declaring and then using' and how it affects scope.
My question is 'why it is allowed in javascript to use a variable directly without declaring it' as most of the programming languages have a strict check on this.
UPDATE : I see the following quoted text as a bad effect of this feature. So, why have this feature at all?
"Suppose there is a globally declared variable x (var x="comparison string") already which i am unaware of and i with intention of creating my own global 'x' inside one of my functions initialize one(x=-1) and there i end up breaking other functionality.
So, is there any good reason at all? for having this feature?

Javascript was intended for very simple scripts in the browser. Requiring variable declarations seemed unnecessary.
Of course, it's an error in the language. And the makers of javascript know that. They wanted to change it. But they couldn't. Why?
Because Microsoft had already reverse engineered JavaScript and created their duplicate JScript, with bugs and all. Microsoft vetoed any changes, even bugfixes, since they were adamant about not breaking anyones scripts. So even if they changed JavaScript, JScript in IE would stay the same.
It's not a good reason. But it's the one we have.
Source: I got my javascript history class from Douglas Crockford: "The JavaScript Programming Language", http://video.yahoo.com/watch/111593/1710507 This part of the story is between 9 and 11 minutes into the video.

Good reasons? Honestly can't think of one, it's one of the few things I really dislike about JS.
It's possible because everything happens within the global scope if not otherwise controlled and JS allows implicit variable creation like this. The cost of this is enormous potential for scoping bugs and pollution, and only benefit given that "this" exists to explicitly define self scope and "window" and "document" exist for global referencing, is saving a few characters - which is no reason at all.

My question is 'why it is allowed in javascript to use a variable directly without declaring it' as most of the programming languages have a strict check on this.
That's the difference between statically and dynamically typed languages. Javascript is dynamically typed, so there is no need to declare first. As it was pointed out in other answers, var keyword is more responsible for scope of a variable than its declaration.
And I don't think that most programming languages have a check on that.

Lua has a similar issue: any non-declared variable is global by default. In the mailing list it's a recurring theme, asking why shouldn't it be 'local by default'. unfortunately, that would introduce very nasty ambiguities in the language, so the conclusion typically is "global by default is bad, local by default is worse"

Because it is a scripting language. Fact kids. And that is how it was designed!