Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Temperment

On innerHTML:

I don't know that there's anything that's more contentious in the DHTML community right now than the place (if there is one) for innerHTML.

It seems that every article or block of code that includes innerHTML these days must withstand withering public criticism or be followed by a years long thread on any number of public forums. Into that maw I assert the following:

innerHTML can be thought of as the DHTML equivelant of C's "goto". It's easily abused by those who do not understand it's dangers (or choose to ignore them), but it's benefits are undeniable. There are about 5 situations that I can think of offhand where using the goto directive in C can significantly simplify any number of problems. They are rare, but knowing that goto is available and being able to reckognize those nasty situations for what they are makes one a more valuable coder. I think the same is true of innerHTML.

The use of innerHTML by newbies is to be discouraged in the strongest of terms. It should be mantra that they be taught to ignore innerHTML as a solution to many of their "starter" problems. The should be taught the value of using textNodes, how modular programing can simplify most of those problems, and how building trees node by node can provide a more complete solution than many of the alternatives. But innerHTML should not receive an instinctive "no" from the web development community, but rather the guru-like raised eyebrow and a query for explination.

As front-end developers we rely on the browser to create a set of DOM nodes out of some text stream every time we request an HTML (or XHTML) document. Why should we not be able to count on that service after the browser loads also? Dissalowing access to that same functionality simply for the sake of avoiding newbie mistakes with such a powerful facility takes the wrong approach. We should be able to rely on browsers to expose most of their functionality to the scripter, otherwise we are wasting our time. innerHTML is not a security risk and there are places where if you need it, you need it bad.

Perhaps it shouldn't be standardized, I'm not sure about my opinion about that, but I do strongly beleive that the solution is not to rally against it, but rather to educate scripters about the right way of doing things, ignoring innerHTML as a solution until it's absolutely necessaray. innerHTML is a powerful tool for thorny problems, but it is not inherently evil.

Let's not promote ignorance over rational use of powerful tools. The right tools for the job...the right tools for the job...