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