IE does something better than Firefox, hell freezes over

Like most web developers, I write markup and Javascript that will work on both IE and Firefox, and if I’m particularly ambitious, Chome and Safari.  I’ve been writing a lot of Javascript lately, which has been a good learning experience but frustrating at the same time.  I don’t have the luxury of using jQuery on my current project — I am pretty much restricted to Prototype for legacy reasons.  I was in the throes of reconciling a piece of code that copied values from one set of input fields to another, then accessing the innerHTML property of the target fields’ containing div.  I was doing simple value assignments ($(“textBox1”).value = $(“textBox2”).value), and in IE everything worked like a peach.  Then I tested in Firefox and, to my amazement, the target input fields remained blank, even though FireBug assured me that the values were in fact being copied.  I was certain I was making a mistake somewhere in code, and spent an hour or so meticulously pouring over every line of Javascript, attempting to find the roadblock.  In desperation, I turned to the Google in search of an answer.  What I found surprised me enough that I felt compelled to write this post.

Firefox does not reflect dynamic DOM changes in the innerHTML property of a given DOM element.

This means that if you set the value of a text box to “123”, then call the innerHTML property of the DOM element that contains the text box, the value of the text box according to innerHTML will appear to be whatever it was prior to your alteration.  In practice, when the page posts back to the server, the value will actually be “123” and not what innerHTML reports, but the fact that Firefox ignores the change gives me yet one more gray hair.

To get around this glaring oversight, I had to use the setAttribute() method on the DOM input element:

$(“textBox1”).setAttribute(“value”, $(“textBox2”).value);

This accomplishes both tasks — updating the actual input value and changing the innerHTML property accordingly.

You’ve won this round IE… you’ve won this round.

2 thoughts on “IE does something better than Firefox, hell freezes over

  1. Jonathan says:

    I actually ran into this the other day. What I found after some research was that innerHTML is actually not a part of the W3C DOM specification. And as we all know, Firefox was built to freak out at the slightest provocation against coding standards, so the fact that Firefox even begrudgingly has any support for innerHTML is something of a miracle.

    Of course, Firefox still supports the “blink” tag, so it’s not one to cast any stones.

  2. @Jon, very true. “innerHTML” is one of those properties that has popularity on its side, though it is not part of the W3C spec. I guess what irks me most is the half-ass support. If you include “innerHTML”, you might as well make it behave like developers would expect. Otherwise just don’t include it at all. Just my $0.02.

Leave a Reply

Your email address will not be published. Required fields are marked *