Jon Fox

May 21, 2009
Code / Javascript

Internet Explorer and the innerHTML Property

by jon

Recently while helping a friend deal with the joys of cross-browser JavaScript when working with widgets, I was reminded of a painful quirk in how Intenert Explorer handles the innerHTML property of DOM elements in some cases.  In particular, DOM elements that are part of a table, or are a child to a table (no matter how many levels deep), can’t have the innerHTML property set at run time.  Doing so produces a completely unhelpful error message and crashes the rendering engine.  This is not only true for tables, but unfortunately happens with several other HTML elements in regard to Internet Explorer.

So, how does one get around this unfortunate problem?  Well, the best method I’ve found is to set the innerHTML property when the element is not yet attached to the DOM or is attached in a “safe” place (usually at the BODY tag).  To make this process simpler, I generalized this into a function that creates a new DOM node of the same type, preserves any attributes I care about, sets the innerHTML property, and replaces the original node in the DOM with this new node having the desired innerHTML.  Here’s the function for reference:

function replace_html(el, html) {
	if( el ) {
                var oldEl = (typeof el === "string" ? document.getElementById(el) : el);
                var newEl = document.createElement(oldEl.nodeName);

                // Preserve any properties we care about (id and class in this example)
                newEl.id = oldEl.id;
                newEl.className = oldEl.className;

                //set the new HTML and insert back into the DOM
                newEl.innerHTML = html;
                if(oldEl.parentNode)
        	        oldEl.parentNode.replaceChild(newEl, oldEl);
                else
		        oldEl.innerHTML = html;

                //return a reference to the new element in case we need it
                return newEl;
	}
};

Hopefully this function will help someone out there work around this problem a little faster than I originally did.

Tags:

34 replies on “Internet Explorer and the innerHTML Property”

  • Michael – or anyone else – my question remains the same over a month later – WHY no support for Intense Debate? I first emailed you weeks ago on problems with the sidebar widget and it's complete failure to update in any sort of timely manner. So far all I've seen are apologies, promises to 'get an update from the team' followed by days on end of silence until I mail again, and sometimes get a response, offering nothing but more apologies and more unkept promises.

  • I'm not convinced that that would be the most likely case. Blogger, as far as I can tell, is generally pretty relaxed about free speech and I don't think that the Bum's blog could be considered 'hatred' except by the most thin-skinned of complainants and similar responding Blogger employees.

    I may be wrong (but I sincerely hope I'm not).

    It might (and I'm not entirely convinced that this is the case) have been something to do with the recent (IMO overblown and confused) betwixt the Bum and Heather over at Why Don't You, but I can't see him dumping his entire blog over that.

    Saying that, he closed it down previously for no reason that I could see, and then resurrected it. Maybe it's just one of those "ah, fuck this blogging malarky" things…

    *shrug*

  • As a side effect of changes in the attributes implementation, the order of attributes reported by innerHTML has changed significantly from IE 7 to IE 8. Here's a quick explanation from our developer team:

    "At the time of the change we did some investigation and found that attributes order has changed to some degree with every new release of IE. Appearances of mostly alphabetic ordering have been accidental. While the jump between IE7 and 8 may have been bigger than previous changes, the order has never been 100% stable. For this reason the side effect was deemed acceptable."

    SO, don't rely on a specific order when parsing HTML code returned by innerHTML. A better solution in any case would be to use attribute.specified to determine if a value has been set.

  • Hi,

    Great work!!!

    My Internet Explorer is faster than before. Nice article.
    Also this article tell me about how Intenert Explorer handles the innerHTML property of DOM elements in some cases.

    Thanks

  • Did not work in my case. Just means more hacking apart some table-filled old web page for the next 2 hours. Of course, my code works beautifully in Firefox

  • Hi, this script really help me out!!
    i dont know why IE has to exist when firefox exist!!

    thanks a lot my friend…

  • Fixed my problem thanks. IE version 8.0.6001.18702
    It seems that the MS guys are in no hurry resolving this to say the least critical bug !!

  • Thanks for this! Saves me a lot of time.

    I did opt to use

    newEl = oldEl.cloneNode(true);

    so that the child elements would be copied over too. I'm not sure if there's a performance hit for that (probably).

    • Comments are closed.

    You may also like