innerHTML vs standards

[aaronbassett]

Ok this is really just looking for people opinions in the on-going battle of which to use innerHTML or standards (DOM methods)

The DOM methods have the usual pros of being supported and part of the standard, so in an ideal world should be forward compatible and work within all browsers. But we know this isnt always the case.

The opposite seems the be true for innerHTML. It is not standards based and as people keep mentioning could be removed at any time (though this is highly unlikely)

The advantages I see innerHTML having is that it is widely supported (maybe even more so than the DOM methods) and in tests always runs faster.


I'm still in 2 minds over which to use. I find myself using innerHTML for adding large or complex amounts to the DOM and the DOM methods for everything else.

How do you approach it? When do you use innerHTML/DOM and under what circumstances would you contemplate changing the method you use?
In your opinion which is the best method?

[Beagle]

I use innerHTML often for things that aren't logically complex, but structurally complex or structurally large. So for example, a huge select element needs to be updated with new options. Instead of iterating over a bunch of DOM methods to create the options, I'll use innerHTML for the speed.

But, anything that involves a lot of javascript references, event handlers, etc I'll use DOM methods for because the behavior of innerHTML is different between browsers, even though most support the property.

Also, anything non-iterative, or small enough, will behoove the use of DOM methods with me.

[brothercake]

Ideally, you should never used innerHTML - it's a bastardization to serialize and treat a node structure as though it were text; it isn't text - it's a node structure ;)

In terms of browser support, there's no difference these days (innerHTML is proprietary, and DOM methods are standard, but everyone implements innerHTML anyway)

In terms of speed, innerHTML is significantly faster, and sometimes there's no denying how much of an advantage that is. You have to be practical, and purist thinking can't always win the day!

Here are ppk's speed tests: http://www.quirksmode.org/blog/archives/2005/04/dom_vs_innerhtm.html

[NancyJ]

I have to admit I'm an innerHTML girl myself - apart from the speed benefits - its just easier to work with - assuming you're just doing a simple text or html replace.
With my 'ajax' I get php to send me the html and javascript to do an innerHTML append or replace - because I'm much better at php than javascript.

[felgall]

There are of course situations where innerHTML wont work and you have to use the DOM such as where you have dynamically added content where you then want to access and update a part of it.

[Kor]

For instance:

When using Ajax and you need simply add new data, innerHTML could be a choise (even, despite NancyJ, I am a DOM boy and I very seldom use innerHTML). But if you need further to handle the new added data (to refere new elements, to change/add their attributes), innerHTML is no good at all, as innerHTML simply visually adds new elements, but it does not really insert them in the DOM structure of the document.

[felgall]

But if you need further to handle the new added data (to refere new elements, to change/add their attributes), innerHTML is no good at all, as innerHTML simply visually adds new elements, but it does not really insert them in the DOM structure of the document.

That doesn't just apply to Ajax, it applies to anything that you add to the web page using innerHTML. It ends up in the page but not in the DOM so you can't document.getElementById() on somenthing where the id is inside of an innerHTML.

[brothercake]

That doesn't just apply to Ajax, it applies to anything that you add to the web page using innerHTML. It ends up in the page but not in the DOM so you can't document.getElementById() on somenthing where the id is inside of an innerHTML.
I keep hearing this ... and it simply isn't true - I've never had any such problem; as far as I've ever found, structures appended using innerHTML are traversible just like any other node structure.

[Kor]

... I had a problem once, for instance, when the element had to have attached an event...

[Basscyst]

Another issue, if I remember correctly event handlers that were added dynamically will not be present in the innerHTML. Perhaps that's what you are reffering to Kor?

For example:

If I were to add an event handler to a button inside a form through script, and then for whatever reason grabbed the innerHTML of the form's parent and then place that string somewhere else in the DOM, the event handler will need to be re-attached, which can be a major hassle.

Basscyst

[felgall]

Attempting to do a document.getElementById() on a tag inside of code that was added using innerHTML just doesn't work in at least some browsers.

If I had not had this precise problem and had to convert the innerHTML into DOM calls in order to fix it then I wouldn't have suggested that this problem existed. It may not exist for all browsers and so those who haven't experienced the problem may not have tried testing it in the right browser to see the problem.

Just to clarify the situation I found where innerHTML doesn't work - in one script I replace an element in the page source with a number of other elements defined using DOM commands. One of those replacement elements has an id and that field is subsequently referenced in the code to produce further updates. Attempting to use innerHTML to update the content of that element does not work.