If you type this phrase into Google, Impressive Webs currently comes in at around result 115. Not to mention the fact that the article that comes up doesn’t really address this issue directly. That’s not a very good ranking for that search phrase — yet somehow people are still finding one of my pages through that search.
It is obvious that developers — likely beginners — are having issues getting the proper results when utilizing the
Well, I’m not claiming to provide the perfect solution/article/resource here, but I thought I would post a few quick points on Internet Explorer’s handling of the
getElementById method that might help a few people. The truth is, I have never had much of an issue at all getting
getElementById to work cross-browser, but after doing some quick research, it seems there are a few things to keep in mind with regards to Internet Explorer.
id Attributes for Non-Grouped Form Inputs
Often, form inputs will have both a
name attribute and
id specified. To prevent problems with
getElementById, make sure the value for the
name attribute for a non-grouped form element is the same as the value for the
id attribute for that same element.
<input type="text" name="address" id="address" value="5th Avenue" />
Don’t Do This:
<input type="text" name="full_address" id="address" value="5th Avenue" />
The reason you should do this is because in Internet Explorer, if you’re trying to target an element using
getElementById, for some reason that browser will search the
name attribute of certain elements on the page, in addition to the
id. Assuming we’ve used the wrong method for coding the name and id values, the code blocks below will get the exact same result in IE7:
var fullAddress = document.getElementById("full_address"); alert(fullAddress.value);
var fullAddress = document.getElementById("address"); alert(fullAddress.value);
In the first code block, I’m targeting the element via the
id attribute that has a value of “full_address”. In the second example, I’m targeting it the proper way via the actual
id. The result is the same in both cases, even though the first example shouldn’t work. Firefox, on the other hand, correctly tells you that the variable “fullAddress” is null.
(NOTE: I neglected to mention in the above section that I was specifically talking about non-grouped elements with the same
id attributes. Radio buttons and checkboxes obviously have to share the “name” attribute, so if they had
ids then there would be differences. See comments section for more.)
form HTML Element Should Not Have a
This problem is very similar to the issue above, so I won’t go into great detail. To avoid problems with
getElementById in Internet Explorer, don’t put a
name attribute on the
<form> element in your HTML.
name attribute for forms is deprecated in XHTML Strict, so it’s not best practice anyhow. The
name attribute was added to form elements in older sites, so if you’re trying to debug a
getElementById issue in IE7 on some inherited code, there could be a conflict occurring due to this fact.
So Do This:
Don’t Do This
<form name="conact_form" id="contact_form">
id="description" on Any Element in Your Page
This is a bit of a strange one, but again is related to the fact that the
name attribute causes conflicts when targeting elements by
id. If you have an element on your page with an
id with the value of “description”, this may conflict with a meta tag on the same page that has a
name attribute with a value of “description”.
Take the following HTML code as an example:
<meta name="description" content="website description" /> ... <textarea id="description" rows="10" cols="25">comments here</textarea>
var textareaBox = document.getElementById("description"); alert(textareaBox.value);
You would expect the value in the alert message to be “comments here”, which it does in Firefox. But in IE 6 & 7, the alerted value will be “undefined”, because the
meta tag does not have a “value” attribute.
So Don’t Do This:
<textarea id="description" rows="10" cols="25">comments here</textarea>
<textarea id="comments_description" rows="10" cols="25">comments here</textarea>
Of course, you may not have a meta description on that page, but just to be safe, don’t use an
id of “description”, in case the page is ever changed.
What if You Can’t Change the HTML?
It’s very rare, but there could be some instances where you’re not able to change the HTML and you still need to overcome one of the conflicts mentioned above. Below are some methods you can use to overcome this problem, although I’m not providing actual code examples — I’m sure you can do a Google search to help if necessary.
- Target an element by checking its
idvalue using the
- Use object detection to discern the capabilities of the user’s browser, then run a specific section of code that will deal with one of the issues mentioned in this article
- If, for example, you’re targeting the
<textarea>element, you could use
getElementsByTagNameto target all
<textarea>elements, then check the value of the
idof the elements within a loop that accesses each element
- Use contextual targeting. In other words, look for the element based on what its parent element is, or whether or not it has any children, etc.
There must still be a lot of legacy code out there that people are having trouble with, otherwise the issues occurring with
Please feel free to comment below on any other bugs or solutions related to
getElementById, and if you still can’t find a solution, I’ll leave the comments open indefinitely for this post, and you can provide a detailed description of your problem.
I knew some of this stuff before but haven’t given it much thought.
But really these are the kind of articles I really like. Straight-forward and easy to understand. Thank you very much!
I’ve seen issues when calling a JS function name is the same name as an input name. Keep that in mind when naming elements as well.
< input name = “address” ….
Thanks for the really detailed post. I will have to stop by and visit here more often.
I had this issue before:) couldn’t found solution, but now I know :) useful information, thanks
bloody hell! how can they (microsoft) be so retarded?!
my script is broken because i’ve got a hidden with name ‘x’ and (later in the html) a td with id ‘x’
now running getElementById(‘x’) returns the hidden, not the td.
you’d think if they wanted to make it fool-proof by checking some name attributes, they could at least check for an element with the right id FIRST, and then revert to the name attribute if nothing is found.
anyway, thanks for the article, very useful description of a very annoying topic.
I was asking myself the same question…
Your article is Soooo wrong it isn’t funny!
IE (before IE8 in Standards Mode) did have a bug where the .getElementById(id) method would return results with an invalid case match on the ID as well as on the NAME attribute which is a blatant error.
Since the name attribute on form fields identifies a group of fields (e.g. checkboxes, radio buttons, or several input fields developers SHOULD NOT set the NAME attribute to the exact same value as the ID attribute. This would cause issues with grouping and more importantly would simply be a failed attempt to hide an IE bug.
There are workarounds for IE’s bug that will fix the IE behavior to work like the specifications and only return the correct element by ID. (see url below)
The other issue is that the NAME attribute IS VALID on other elements including [meta] tags, [form] tags, [a] tags, [iframe], [frame], tags etc.
Thus any attempt to workaround the issue by restricting how the attributes are used is heading down a very bad path towards trouble.
When I said that the name and id should be the same for input elements, I was referring to non-grouped elements. I should have made that clear. I’m obviously quite well aware that checkboxes and radio buttons are grouped by the “name” attribute, and so are my readers. That was a small oversight on my part, but I really don’t think anyone will make that mistake anyhow, so your comment is technically correct, but only with regards to the “grouped” input elements.
Thank you for pointing that out, I’ll make a small edit to correct the wording on that. As far as the rest of the article, I still stand by all of my workarounds, unless someone can show otherwise.
thanks for pointing out these problems with IE.
I had so much problems with getElementById in IE8.
And so much time trying to debugging my codes.
Until I find this article. I thought the problems are with my codes.
THANKS THANKS THANKS MILLION TIME
Useful article, Louis. It’s worth pointing out that jQuery (and any other JS framework worth its salt) handles these bugs via its abstraction layer. Apparently, the problem affects Opera, too.
This is what am searching a lot, ur article is usefull to find my mistakes
But i have a doubt, My PC is installed with IE6,
I have used GetElementByID(‘id’).style.dispaly=”none”; and GetElementByID(‘id’).style.dispaly=”none”;
in my program my webpage get loads perfectly in IE6, but the same page when get loads in FF,Opera, google chrome, the id in tag get loaded but the web page alignment changes.
I cant find where am lacking, Any one can give me a solution
Thanks for the article, IE is a pain to code for and posts like this help us developers out immensely!
Cheers and thanks for the useful, well written article!
Thank you so much!!!
I spent about 3 hours trying to figure out why IE7 won’t ****ing get the value of my “textarea”. Funny enough I did all the mistakes you’ve mentioned here, so although I instinctively tried each one of the solutions (without knowing if it’s right) it still did not work.
thank you again!
I want to add one more point here where we can find difference b/w IE and firefox… If u want access getElementById value to a variable which is not defined(Ex:With ‘var’ key word). It ignores and validates the data in the form in Mozilla but its not the case with IE7. So declare variables in js before you use it. It may avoid these situation. This may be useful.
I had an input field with ID=passwords
This (f..§è§'(è##§è) IE was then looking at the HEAD !!!! section where I had
<meta name=’passwords’ ..
Another poorly designed feature from Microsoft !
Simply-very useful and impressive article which solved my production problem in IE
Solved my problem. Very grateful
Thank you so much, Louis!
Thank you for this useful article
have a nice day
Very good article, thank you.
I’ve got also a problem with IE8 using getElementById():
<th class="hdLine" style="font-size: .8em;"> <!-- counter -->
<span id="curNoOf" name="curNoOf"/>
<span id="reqNoOf" name="reqNoOf"/>
//1st call returns the correct object (1st span element)
var theDOMObject = document.getElementById(“curNoOf”);
//2nd call some lines below returns null!
theDOMObject = document.getElementById(“reqNoOf”);
The reason seems to be the definition of the span-tags. As soon as the span-tags were closed using instead of just the 2nd call of getElementById() works as expected.
So the correct HTML to solve this problem must be:
<th class="hdLine" style="font-size: .8em;"> <!-- counter -->
<span id="curNoOf" name="curNoOf"></span>
<span id="reqNoOf" name="reqNoOf"></span>
I know that the span tag is not an empty HTML element and therefore the correct definition is
<span...></span>. Firefox can handle also
<span.../>and returns at both getElementById() calls the relevant elements – but IE(8) doesn’t.
So keep in mind to use the correct definitions of the HTML elements (e.g. described at w3schools.com).
I’ve tested it with FF27.0.1 and IE8 but not with other tags than span.
Please remove this comment in case of I’m barking up the wrong tree.
Kind regards Uwe
That sounds correct. The browser needs to close that tag, so it’s viewing everything after it as part of the same tag. Probably shouldn’t act that way, but that’s IE. :)
Also, keep in mind that “w3schools” is not part of any official web standards. It’s just a tutorial website. They have nothing to do with the “W3C”. The real specification is here:
How about non-form elements, like DIVs?
Nailed it, very helpful, thank you. It was the name and id issue. More specifically, getElementById in IE9 found the element with only a name, but in IE11 getElementById would not find the name-only element. Adding the id attribute to the element in addition to name solved it.
var table = document.getElementById(“Table”);
var newRow = table .insertRow(0);
newRow.id = “Test”;
newRow.name = “Test”;
var newCell = newRow.insertCell();
newCell.innerHTML = “Welcome”;
If you create an element from JS like above, the name attribute doesn’t display in IE11.
Every body is welcome to share their knowledge on this.
I don’t think you need the name attribute, only the ID. What are you trying to use the “name” attribute for?
Also, you can instead try doing
newRow.setAttribute('name', 'Test')as an alternative method to create it. But again, I don’t think you need it at all.
Sorry, I don’t understand how to format the code with indentations. It looked good when I submitted it.