I have a love-hate relationship with innerHTML.
On the one hand, it’s proprietary. It’s certainly not part of the W3C DOM. It’s also not very subtle. It takes a single argument — a string — and bungs it into an element, regardless of whether the string contains valid or even well-formed markup. It’s a lot safer (although more time-consuming) to use DOM methods like createElement, createTextNode and appendChild.
On the other hand, innerHTML is very well-supported. In fact, it enjoys better cross-browser support than some official DOM methods and properties.
Does this make it a de-facto standard? Possibly. People are already paving the cowpaths with innerHTML when it comes to Ajax. See the AHAH microformat, for instance. It’s a super-simple way of taking the responseText property of the XMLHttpRequest object and slapping it into a specified part of a page. It’s the very essence of Ajax: updating a portion of a page instead of refreshing the whole page. That’s pretty similar to the way I’ve built most of my Ajax apps so far.
Using a proprietary property like innerHTML does make me feel slightly dirty. I justify its use by telling myself that XMLHttpRequest is also proprietary, which is true. There’s no way to make Ajax work without making some sort of Faustian pact with non-standard technologies… non-standard in the strictest sense, anyway.
But there’s a specific situation where innerHTML can let you down. If you serve up your XHTML with an XML mime-type, you can’t use innerHTML. If you want your documents to be treated as XML, you’ll have to forego the convenience of HTML-specific properties like innerHTML.
Or at least that was the case. Firefox 1.5 has just been released. Among the many changes made to the browser, it now supports the use of innerHTML even on XHTML documents.
Maybe it’s time I worked out my “issues” with innerHTML. It looks like it’s here to stay.
I just hope it doesn’t lead me down a slippery slope to document.write.
Posted by Jeremy on Thursday, December 1st, 2005 at 3:04am
Comments
I have never and will never use innerHTML for anything other than testing. It’s so unstructured, it feels like bad programming practice and is on the same level as document.write() (which will never work in XHTML and I will also never use in HTML).
I’m fairly disappointed with Firefox for adding support for it. People should just learn to use the much more structured DOM2 methods. However, it is good that Firefox’s implementation for XML documents will fail if it’s not well formed, unlike Opera.
# Posted by Lachlan Hunt on Thursday, December 1st, 2005 at 4:47am
I do not believe you should ever use innerHTML, no matter how convenient or tempting. I have done most of my XML work in the non-web world writing web applications in Delphi. It is very tempting to put together an XML fragment using string function and add to an XML document. But I have been bitten badly by doing this. The XML parser properly understands the XML document character set and the escaping rules, it is very easy to end up with bad data in the XML.
Just do not go there, write some JavaScript helper functions and do it the right way.
# Posted by Martin Tomes on Thursday, December 1st, 2005 at 1:57pm
I think innerHTML is sexy. It’s so easy as to be sleazy.
Just because the DOM2 methods are more structured doesn’t mean that there isn’t room for a quicker and easier approach to content/element insertion. I hear the same argument about HTML vs XHTML. “Because people can screw up HTML, we should force everybody to use XHTML.” Next you’ll hear people say that JavaScript shouldn’t be used because it’s dynamically typed.
I don’t know about you guys but I’d rather save myself the time of having to code 20 lines of createElement/appendChild’s when a single innerHTML will suffice.
# Posted by Jonathan Snook on Thursday, December 1st, 2005 at 4:47pm
There there… it’s ok. We forgive you, Jeremy… :P
I’m with Jonathan. If it’s widely supported, has proven to be faster (http://www.quirksmode.org/dom/innerhtml.html), why should we not use it?
It’s funny how discussion about innerHTML is starting around the web at the moment, and i bet it’s due to the AHAH microformat. Someone asked me about the browser support of this property when i posted a link to AHAH. Funny. :)
# Posted by André Luís on Thursday, December 1st, 2005 at 7:43pm
Jeremy, I think I too am on the fence with innerHTML. It works and I don’t think it’s bad programming practice. It’s way too widely supported, and browsers are even going forward with it (like you mentioned 1.5 giving innerHTML xml support (shouldn’t it be called innerXML)).
# Posted by Dustin Diaz on Thursday, December 1st, 2005 at 9:44pm
Well written Jeremy and I’m not sure which side I’d drop on that one either. I think its about making educated decisions on these grey areas on a case by case basis.
# Posted by nortypig on Thursday, December 1st, 2005 at 10:13pm
On the other hand… MochiKit has a pretty nice functional system of shortcuts for generating DOM structures to replace those 20 lines of createElement() / appendChild() calls.
http://www.mochikit.com/doc/html/MochiKit/DOM.html#creating-dom-element-trees
# Posted by l.m.orchard on Friday, December 2nd, 2005 at 7:33am
Using DOM methods instead of innerHTML is obviously the more correct course of action. But that’s only useful if the data you are inserting is in an object format already. What happens when you receive HTML markup as a text string - how does one convert that to a DOM object and insert it?
A typical example is inserting an entry from an RSS feed into an HTML page. The vast majority of feeds use CDATA or entity escaped markup for the content - that’s just a text string on HTML markup. What can be done other than innerHTML it right into the current node?
I’m toying with the idea of pushing the markup through a DOM Parser and get an HTML tree - but its not as well documented as XmlHttpRequest.
But then what happens if the stringified markup is invalid?
This is a trade off between the purity of unobtrusive javascript, and the spirit of DOM updates, and the practical problems out there on the web.
Unfortunately, most of the HTML out there is basically a text string. But then Internet Explorer has been dealing with that problem for years.
# Posted by Isofarro on Friday, December 2nd, 2005 at 2:04pm
I’ve been struggling with this same issue for a while now. And (I surprised myelf here) I came out in favor of innerHTML. I may have a differernt perspective though. I work primarily on LARGE applications, where maintainability is priority #1.
So if I’m populating a page with data via ajax, which is easier to maintain? 1. A page that delivers XML, followed by many (many) lines of javascript removing DOM elements, creating DOM elements, appending elements etc. Or, 2. A page that delivers HTML, followed by one line of javascript that inserts it in the page.
Option 2 is infinitely easier to maintain (especially across developers). I’ve thought about this and written about it (http://www.agavegroup.com/?p=43) and just can’t get away from the simplicity of innerHTML (and the fact that it works 100% of the time…)
I think what would be nice would be if JavaScript had syntactic sugar that let you type (valid!) XML, possibly with some sort of substitution mechanism, and have it turn out as the DOM object.
I’d also like a pony.
# Posted by David Glasser on Friday, December 2nd, 2005 at 9:43pm
Ooh, I want a pony… no, on second thought, I want a llama. Or an alpaca.
As for innerHTML… I always feel dirty when I use it, so I don’t use it often. I’m a casual user. Just when I’m by myself and know it’s not hurting anyone but me.
# Posted by Aaron Gustafson on Saturday, December 3rd, 2005 at 10:23pm
innerHTML is ugly. Don’t use it. Imagine XHTML with multiple namespace, I think innerHTML will fail to have consistent cross-browser output.
# Posted by minghong on Sunday, December 4th, 2005 at 5:59am
Someone should just write a library that takes a string of (X)HTML, parses it for tag structure and then adds it to a given element using the "standard" methods. Everyone’s happy! ;)
# Posted by Shaun Inman on Monday, December 5th, 2005 at 3:55pm
Savvy meetin’ you up here Jeremy. We should get some lawn chairs for our little fence. I’ll bring along some fishing poles.
@Shaun: Nah. More talk, less development. It gives us something to ponder.
# Posted by Dustin Diaz on Wednesday, December 7th, 2005 at 5:02am
I’m with Isofarro. I have a PHP script that connects to MySQL and returns me a formatted HTML table. I then load that into a page without having to refresh via xmlhttprequest. It works great except for in Explorer which does not allow writing innerHTML to a table.
I am a beginner and innerHTML is a good way for me to get results without having to deal with 20 lines of DOM work that twists my brain to pieces.
If anyone knows a way to simply get MySQL data into a page and resort/ re-query without refreshing the page without using innerHTML, drop me a line!
# Posted by Brooks on Tuesday, December 13th, 2005 at 6:47am
Risking a little bit of deviation I would appreciate some advice from you guys. I have this slow real slow piece of code involving innerHtml. Now we are thinking of changing it to DOM just to speed up things. The table generated is small average 6 rows and 4 columns. Do you think DOM will speed it up? I dont see how!The looping and all will remain the same.
Jonathan Snook said: "I think innerHTML is sexy. It’s so easy as to be sleazy."
Oh, great. Now innerHTML will be forever personified in my mind as a smirking, raven-haired seductress in a dress cut down to here and slit up to there, throwing herself at me despite my best efforts to walk the straight and narrow of semantically correct code.
Maybe I just need to get out more.
# Posted by Adam Messinger on Sunday, December 18th, 2005 at 7:41am
I had a chance to attend Adaptive Path’s "Designing and Building with Ajax" seminar and this subject came up (I was the one that brought it up). The Ajaxian.com guys were there - I can say they appear to be VERY experienced on the subject. And here’s what they had to say on the matter:
1) innerHTML is faster than DOM "createElement" methods. Really. Potentially Wicked Fast(tm) in comparison.
2) Use of innerHTML is recommended if your need is one way. That is, you are just presenting content, after which you are "done." However, if you need to refer/traverse a DOM branch that you are changing, then you should use "createElement" DOM methods.
In summary, which to use? Answer: both. It depends on your case.
# Posted by Jeffrey Schrab on Tuesday, December 20th, 2005 at 7:36pm
Well said, Jeffrey. I made a similar point in my own post referencing this one. As with most things, compromise and moderation are the best answer.
# Posted by Adam Messinger on Tuesday, December 20th, 2005 at 8:12pm
Sorry. Comments are closed.