Work
SubscribeIE 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();
}
Oh. My. God. I have seen some funky stuff in the past from IE, but this takes the biscuit...
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.
@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!
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.
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!
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???
[...] name attribute is being striped away from forms and the like (obviously not inputs elements). No more excuses IE. [...]
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.
@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!
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!!!