IE 7 breaks getElementById

First let me say this took me ages to work out how this was going wrong, and that this bug affects both IE6 and IE7.

IE is treating the name attribute on forms as the ID attribute, causing the getElementById to return very unexpected results.

See the example of getElementById breaking.

I’ve not investigated this beyond the FORM element, but the problem is this:

If you have an element whose ID is ‘container’, and a form whose name is ‘container’ but ID is anything else, say: ‘formContainer’, running the following:

var elm = document.getElementById('container') elm.style.display = 'none';

In IE only, the form will disappear. Correctly in all other browsers, the element whose ID is container will disappear.

I can only assume this harks back to when the name attribute was being used as the identify, but has now been formally depreciated by W3 (for XHTML) and only around for backward compatibility.

The solution is simply not to use the name attribute on forms. You can still easily target the form without it:

document.getElementById('submitButton').onclick = function() { // do some code this.form.submit(); }

16 Responses to “IE 7 breaks getElementById”

  1. Oh. My. God. I have seen some funky stuff in the past from IE, but this takes the biscuit…

  2. Not using names on form field attributes doesn’t seem like a good idea to me. How is the server side code going to know which values are what? IDs don’t survive a POST.

  3. @Mike – the key I guess is to only use the name attribute on input (and alike) elements and to ensure they are unique when compared to IDs.

    Personally, I never use the name attribute on a form, it just so happened the project I was working on someone else had done causing a good few hours of confusion!

  4. Am I surprised that IE7 does things differently than all other browsers? Not really. Does it really p…. me off? oh yes.

    Someone should tell the guys at MS that they should start focusing on one thing: Making a better OS, and stop making life miserable for the rest of us.

  5. This page here:

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

    Describes a wicked workaround for Internet Explorer. Rather than not supply a name for the fields (which Mike pointed out, will kill the field data on the request), it simply, cleverly, fixes the IE method, to return the correct element, every time, even if there is a conflict with the name attribute.

    I just wish I’d seen this fix sooner!

  6. Thanks for the post here. I just wasted about an hour before I found this out. IE still sucks. Of all DOM methods, how could they fuck this one up and survive???

  7. [...] name attribute is being striped away from forms and the like (obviously not inputs elements). No more excuses IE. [...]

  8. This is a well-known, long-standing bug in IE. It’s one of those ones that are hard to fix because it would break a lot of pages which rely on the incorrect behavior. Form elements simply don’t need a name attribute. For inputs, the easiest workaround for me has been to simply ensure that all inputs use the same value for their ID as for their name.

  9. @Steve re: “Form elements simply don’t need a name attribute”

    That is _WRONG_! They absolutely need a name, because that is what name is used when the form is submitted on the URL, or as a POST (instead of a GET)

    George pointed out the first bug with IEs getElementById, but there is another one:
    http://webbugtrack.blogspot.com/2007/09/bug-154-getelementbyid-is-not-case.html

    Where it isn’t case sensitive either meaning”

    “thisID”
    “thisid”
    and “thisId” all match!

  10. I was pulling my hair out trying to figure why my script was working in every other browser except for IE! Especially when getting no errors!
    Thanks for the revelation!!!

  11. I couldn’t believe it, my document.getElementById(id); javascript function wasn’t working in IE because I had a <a name="id"> HTML tag! So it’s not just form tags this affects!

  12. I tried workaround #3 from webbugtrack.blogspot.com (above) and had no luck with this function:

    
    function removeAttachment(AttachDivID) {
    	var theDiv = document.getElementById(AttachDivID);
    	theDiv.parentNode.removeChild(theDiv);
    }
    

    invoked by this:

    
    <div name="AttachDiv1" id="AttachDiv1">
          <input type="file" name="Attachment1" id="Attachment1" />
          <a href="#" onclick="removeAttachment(AttachDiv1)">Remove</a>
    </div>
    

    Does my function rely on still other methods not correctly implemented by IE?

  13. The main bug and the one reported by Sampson are worthy and need to be fixed by IE team. Case in-sensitiveness is the major one which is causing problems where the ids are auto generated for HTML elements. In such environments we are help less. IE should get out of these as early as possible.

  14. I dont know if its the same, but this does not work either:

    var myName = document.getElementById("myName");

  15. Confirming at least IE8.0 on Vista does not support a handler function having

    //this line inside handler breaks stuff
    var myName = document.getElementById("myName");
    /// called from
    <form onsubmit="mybrokenHandler(); return false;">
    

    the first line breaks the handler function if the names are the same, stops executing.
    Then
    calling the handler from the second line
    ignores the return false and actually submits.
    Code works fine under at least Google Chrome.
    …why can’t I have two code escape sequences on this blog, it would make things easier? Noo–it breaks if I put the F o r m word in it. Better instructions on how to escape code, please.

  16. Oh my god, i think my brain explode while im fixing this problem =)
    Thanks a lot, Remy!

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight