Inner workings of innerHTML

Question

I was trying to iteratively change the innerHTML of an Id, like:

document.getElementById("test").innerHTML += "<br />"

and

document.getElementById("test").innerHTML += "<table>" + blahblah + "</table>"

but I found that it didn't necessarily put my tags in sequence.

Of course, this method sucks, and I just changed everything to keep adding to a string, which I assign at the end to the innerHTML of the Id.

My question is:

What exactly is innerHTML doing to the tags I'm inserting, is it deterministic, is it brower-specific?

Answer 1

In my experience most of the time a browser tries to correct the HTML¹ before injecting it into the DOM. If you wanted to build a <ul> this way:

someElement.innerHTML += '<ul>';
someElement.innerHTML += '<li>some li</li>';
someElement.innerHTML += '<li>some other li</li>';
someElement.innerHTML += '</ul>';

In for example Chrome that would have resulted in:

<ul></ul>
 <li>some li</li>
 <li>some other li</li>
<ul></ul>

So, innerHTML can give unpredictable results, because every time you use it, the HTML is corrected by the browser (and browsers differ in the way they do it too). This is especially true for table/table elements (and even more especially so in IE (MS invented innerHTML by the way;)). If you want your html to be absolutely the way you intended it, stick to DOM methods (createElement/appendChild etc.), or first build up a string of the complete element you want to insert using innerHTML, then insert it, in other words, don't use innerHTML with strings containing incomplete HTML.

To be complete I cite from PPK's quirksmode:

If you remove elements through innerHTML in IE, their content is wiped and only the element itself (i.e. opening and closing tags) remain. If you want to remove nodes that you may want to reinsert at a later time, use DOM methods such as removeChild()

¹ more technical: I think every browser applies its own HTML fragment parsing algorithm.

Answer 2

InnerHTML isn't doing anything, but the browser is free to change things around however it likes. You can see this happening if you open a page in Firefox and open Firebug along with it. When you view your HTML, you might find that some elements are not even there anymore.

Firefox's most surprising action, to a newcomer, is to change all HTML to what appears to be XHTML.

As to your method, I don't think it sucks at all. I think it's pretty cool, in fact. So thanks!

And have an upvote for that :-)

Answer 3

I encountered a similar problem very recently. As there was barely any useful documentation available, I had to learn by experience. Here goes.

Browsers seem to be parsing innerHTML as soon as any amendment is made. Through such parsing, any invalid HTML snippet will be rejected / added to and made into a valid snippet!

Moral of the story: Whenever you are modifying innerHTML, ensure that the HTML you are inserting is valid. Thus, ...innerHTML += "<table> ... </table>" should work fine but ...innerHTML += "<table>"; ... .innerHTML += "<\table>" would probably result in unexpected behavior.

This is happenning because in the latter case, as soon as you insert a <table>, the browser parses the string and adds a complete node (thus completing your incomplete code). Hence, anything you add later would appear as a sibling of the table node and not as a child as you had originally intended.