CodeinWP CodeinWP

Avoiding Problems With JavaScript’s getElementById Method in Internet Explorer 7

By / / 30 Comments

Updated:

Targeting Elements Using getElementByIdEvery week this website gets about 700 unique visits from Google searches, mostly from people searching for solutions to problems with JavaScript and CSS. I’m flattered, and I hope I can continue to publish useful articles that will assist people and help with the exchange of ideas and techniques. One search phrase that leads surfers to my site pretty much every day is something along the lines of “getElementById explorer 7”.

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 getElementById method available in JavaScript, particularly in Internet Explorer versions 6 and 7. And since the users seem to be searching through dozens of web pages looking for a solution to their particular problem, then obviously the pages discussing this JavaScript method are either too confusing or don’t specifically provide a practical solution.

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.

The name and 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.

Do This:

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

The form HTML Element Should Not Have a name Attribute

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.

Also, the 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:

<form id="contact_form">

Don’t Do This

<form name="conact_form" id="contact_form">

Don’t Use 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>

Now take the following JavaScript code:

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>

Do This:

<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 id value using the getAttribute method
  • 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 getElementsByTagName to target all <textarea> elements, then check the value of the id of 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.

Conclusion

There must still be a lot of legacy code out there that people are having trouble with, otherwise the issues occurring with getElementById would not be so common. Hopefully this article will help users quickly find solutions to why this often-used JavaScript method is not producing desired results in Internet Explorer’s browsers.

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.

30 Responses

  1. Ida says:
    July 31, 2009 at 6:31 am

    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!
    Keep it up blogging about JavaScript.

    Reply
  2. Jonathan says:
    July 31, 2009 at 10:06 am

    Good article! I wish I knew when I’d stop feeling like a “beginner” with Javascript.

    Reply
  3. Don says:
    July 31, 2009 at 1:58 pm

    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.

    function address(){

    }

    < input name = “address” ….

    Reply
  4. Matt Longley says:
    August 1, 2009 at 8:41 am

    Thanks for the really detailed post. I will have to stop by and visit here more often.

    Reply
  5. Kartlos Tchavelachvili says:
    August 1, 2009 at 11:54 am

    I had this issue before:) couldn’t found solution, but now I know :) useful information, thanks

    Reply
  6. pstanton says:
    August 12, 2009 at 4:05 am

    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.

    cheers.

    Reply
  7. Jacob says:
    August 22, 2009 at 7:17 pm

    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)

    http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html

    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.

    Jacob

    Reply
  8. Impressive Webs says:
    August 22, 2009 at 10:52 pm

    @Jacob:

    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.

    Reply
  9. Vincent Tsang says:
    August 29, 2009 at 4:45 am

    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

    Reply
  10. Bobby Jack says:
    October 19, 2009 at 12:01 pm

    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.

    Cheers,

    – Bobby

    Reply
  11. manoj says:
    December 18, 2009 at 6:19 pm

    hi,
    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

    Reply
  12. Kawika says:
    March 7, 2010 at 4:22 am

    Thanks for the article, IE is a pain to code for and posts like this help us developers out immensely!

    Reply
  13. Mark says:
    August 13, 2010 at 10:57 pm

    I found another one that wasn’t mentioned in your post. JavaScript variables!
    Like so:

    
<html>
<head>
  <script type="text/javascript">
 	function getMyImg() {
 		var myFirstImg = document.getElementById("myFirstImg");
 		mySecondImg = document.getElementById("mySecondImg");
// Above line will fail on IE but work on Firefox!
 		if (myFirstImg.src == mySecondImg.src) {
 			alert('src=' + mySecondImg.src);
 		}
 	}
 </script>
 </head>
 <body>
 	<a href="#" onclick="getMyImg(); return false;">Do 
 Something</a>
 	<img id="myFirstImg" src="sample.png" />
 	<img id="mySecondImg" src="sample.png" /> </body> 
 </html>

    Cheers and thanks for the useful, well written article!
    -Mark

    Reply
  14. Lital says:
    October 28, 2010 at 12:24 pm

    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!

    Reply
  15. Samhitha Reddy Kandi says:
    September 13, 2012 at 9:51 am

    Hi,

    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.

    Thanks

    Reply
  16. alexandre says:
    February 12, 2013 at 10:39 pm

    Thanks !

    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 !

    Reply
  17. sunil says:
    April 2, 2013 at 1:57 pm

    Simply-very useful and impressive article which solved my production problem in IE

    Reply
  18. gopu says:
    May 29, 2013 at 9:29 am

    Good article..

    Reply
  19. Intotito says:
    May 30, 2013 at 2:43 am

    Solved my problem. Very grateful

    Reply
  20. David says:
    July 19, 2013 at 8:47 am

    Great!

    Thank you so much, Louis!

    Reply
  21. Asma says:
    June 19, 2014 at 5:09 am

    Thank you for this useful article
    I wish some day be an expert in Javascript , I have a lot to learn and know, you were very helpful and I wish you luck and courage

    have a nice day

    Reply
  22. UweLm says:
    June 30, 2014 at 4:33 am

    Very good article, thank you.
    I’ve got also a problem with IE8 using getElementById():
    HTML:
    …
    <th class="hdLine" style="font-size: .8em;"> <!-- counter -->
    <div align="left">
    <span id="curNoOf" name="curNoOf"/>
    </div>/
    <div align="left">
    <span id="reqNoOf" name="reqNoOf"/>
    </div>
    </th>
    …
    Javascript:
    //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:
    HTML:
    …
    <th class="hdLine" style="font-size: .8em;"> <!-- counter -->
    <div align="left">
    <span id="curNoOf" name="curNoOf"></span>
    </div>/
    <div align="left">
    <span id="reqNoOf" name="reqNoOf"></span>
    </div>
    </th>
    …
    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

    Reply
  23. Rafael says:
    September 30, 2014 at 5:11 pm

    How about non-form elements, like DIVs?

    Reply
  24. Cris B says:
    February 27, 2015 at 3:33 pm

    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.

    Reply
  25. Arpit dak says:
    December 23, 2015 at 5:18 am

    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.

    Reply
    • Louis Lazaris says:
      December 23, 2015 at 7:58 am

      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.

      Reply
  26. dbareis says:
    July 11, 2016 at 7:44 pm

    Excellent article

    Reply
  27. James Botts or Jim Botts says:
    April 28, 2021 at 2:25 pm

    Sorry, I don’t understand how to format the code with indentations. It looked good when I submitted it.

    Reply

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field and deep URLs are not allowed in the "Website" field. If you use keywords or deep URLs, your comment or URL will be removed. No foul language, please. Thank you for cooperating.

Markdown in use! Use `backticks` for inline code snippets and triple backticks at start and end for code blocks. You can also indent a code block four spaces. And no need to escape HTML, just type it correctly but make sure it's inside code delimeters (backticks or triple backticks).