Search site

Add to Google

Send a comment back

If you are not a registered user, your comment will be moderated and may be deleted subsequently by the author if it is deemed to contain inappropriate materials. All embedded URLs will automatically be turned into anchors, so there is no need to wrap them in HTML tags

by:Guest User
Your Name:
Your URL/Blog
(to link back to your site):
getElementById, getElementsByName in Internet Explorer and Firefox back

Firefox-ie-logo

I ran into this problem recently in the use of document.getElementById() call in Javascript, which looks like it is broken in Firefox. I decided to dig deeper, and in the process of solving it, discovered some interesting differences in behaviour between Internet Explorer (version 8) and Firefox (version 3.*).

The problem stems from the call to the prototype.js function $(), which is a very convenient shorthand for document.getElementById() call to the DOM. In IE, this call returns me the relevant DOM element, whereas in Firefox, it consistently returns NULL. At first, I thought prototype.js was broken, but after downloading the latest release candidate, I found that the problem still persisted.

As it turns out, the problem is to do with how you declare the form element in the first place. I declared it as:

<textarea name="refs"></textarea>


So, as far as Firefox is concerned, I have not declared an id on the textarea, and this is the reason why it returns null. Fine, it looks like Firefox's implementation of document.getElementById() is less lenient than IE, where it falls back on to the name of the element if the id is not specified. Obviously, the fix to get the above to work with Firefox is:

<textarea name="refs" id="refs"></textarea>

Which is not too much of a problem.

As a developer, I obviously like IE's approach of defaulting to the most logical attribute, as it makes my life easier. However, I also know that this kind of ambiguity will one day come back to bite me elsewhere. A good analogy of this is the "use strict" directive in Perl. If you use this directive, it behaves like Firefox, in requiring you to pre-declare everything before you can use them. Without this directive, Perl code behaves like IE in this case, where it picks up the value from wherever it can. I still have to maintain some Perl code which are written without "use strict", and it is not particularly nice. So I guess the moral of the story is a little pain now saves a lot of pain down the road.

What is it about document.getElementsByName() ? Well, I discovered also that calling document.getElementById() on a group of radio buttons does not return you the array of buttons as you'd hope for. Instead, it returns you the first (or maybe last?) button. In this case, if you want to iterate through the buttons to see which one is selected, or to select one yourself, you'd have to use the document.getElementsByName() instead. Here is the example:

<input type="radio" name="export_mode" id="export_mode[0]" value="PDF" checked="checked" />
<input type="radio" name="export_mode" id="export_mode[1]" value="XML"  />
<input type="radio" name="export_mode" id="export_mode[2]" value="HTML"  />

<script>
function getSelected() {
    var mode = document.getElementsByName('export_mode');
    for (var i = 0; i < mode.length; i++) {
        if (mode[i].checked) {
            return mode[i].value;
        }
    }
}
function setSelected(value) {
    var mode = document.getElementsByName('export_mode');
    for (var i = 0; i < mode.length; i++) {
        if (mode[i].value == value) {
            mode[i].checked = true;
            break;
        }
    }
}
</script>


In the above example, you can still use document.getElementById() to retrieve individual buttons in the radio group because each button has a unique id. However, this call is only useful if you know for sure how many buttons there are in the radio group as you can not iterate through the group using this call.

back


 by by David at 21 Aug 2009 12:09:13
Copyrights © Transcraft Trading Limited 2006.All rights reserved.