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?

Moluccas

Pls. give a specific example. WHICH tags does WHAT browser put into WHAT sequence? – Currycomb

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.

Roundly

That's right. And adding to it, the browser parses innerHTML even if the innerHTML belongs to a <textarea> (where it should not be parsed)! – Stomatitis

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 :-)

Rustproof

THe reason it isn't a good method besides the issue I brought up is that it's slower for the browser to process, than one assignment to the innerHTML. – Moluccas

@Lance Roberts -- I see. Well, that makes perfect sense. And of course when you calculate "slower" you're including the time to get the InnerHTML out of the element and into a var; catting the new stuff -- "<br>" in your example -- onto the end of that var; and storing the var back into the HTML. Can that really be true? Browser is a real dog -- a bowser -- if so. – Rustproof

Answer 3

Although innerHTML is not part of the w3c DOM, it is supported by all browsers. Originally it just appended the string as-it-is to your element. All major browsers however modify your string and make the string a valid html markup. This is browser specific and not explicitly defined in any official standard. I like the way Mozilla explains the workings of innerHTML.

Pozsony

innerHTML is specified in HTML5: w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0 – Stumper

Answer 4

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.

Stomatitis

Answer 5

In my think you should put text not to doucumet.getElementByID("Name").innerHTML I think you should just put in html. use a sign over ~ it is if you put in innerHTML something you can get some informations from API. Like me. In script tag. I used console.log and document.getElementById console.log('ID: ' + profile.getId()); console.log('Name: ' + profile.getName()); document.getElementById("Name").innerHTML =+profile.getName()+`

Touchback