Working together for standards The Web Standards Project

Dan Webb is a standards-savvy JavaScript developer who has run into a dilemma familiar to many of us…

Suppose you want to generate and insert some markup using JavaScript. You’ve got two options:

1. You can use the non-standard innerHTML which is quick and easy but proprietary or
2. You can use standards: DOM methods like createElement and createTextNode which carry the W3C’s stamp of approval but which can be finicky and repetitive to use.

Dan has resolved this conundrum by creating an elegant lightweight script to take the pain out of creating markup with JavaScript. He has provided documentation and he explains his reasons for writing the script.

Like all the best solutions, it does one thing really well instead of trying to be all things to all people. This 1K file will prove invaluable to anyone who’s been faced with the same dilemma. It’s a guilt-free way of painlessly adding nodes to the DOM tree.

Your Replies

#1 On April 13th, 2006 8:33 pm Pig Pen - Web Standards Compliant Web Design Blog » Blog Archive » DOM Builder replied:

[...] DOM Builder – a script by Dan Webb which is, as Jeremy Keith writes, a guilt-free way of painlessly adding nodes to the DOM tree [...]

#2 On April 14th, 2006 12:45 am Dustin Diaz replied:

Guilt free? Is that the only reason we should use it? Why not work toward standarizing innerHTML, eh? Really man, what’s wrong with it? Hey, just so we don’t feel bad, we can call it innerXML, yea? I have to admit though, surely Dan’s DOM builder is real slick and cool. But seriously speaking, c’mon now… can’t the W3C just work on creating some sort of standard innerXML? It’s just too easy to ignore it. We can’t seriously be swayed to use “Dan’s DOM Builder” just because it is “stamped with W3C approval” Surely someone else feels the same.

Jeremy, just last december you mentioned the innerHTML love-hate relationship you have?

With the emmergence of ajax and xmlHttpRequest… what are we supposed to do about that? Surely we’re not going to stop using xmlHttpRequest just because it’s non-standard. So like I mentioned, why not just standardize innerXML?

#3 On April 14th, 2006 3:44 am Stephanie replied:

Dustin the W3 approval is all I need to know that it is trustworthy and reliable, still I agree with all the other technologies out there why use this when they are plenty of other great choices. But it is still a great script and time saver no doubt.

#4 On April 14th, 2006 6:54 am WaSP Member Jeremy Keith replied:

Dustin, did I say there was anything wrong with innerHTML?

I simply described it as being quick, easy, and proprietary. I didn’t say it was evil. I didn’t say it was bad. I simply said it was proprietary. That is a fact, not an opinion. Don’t conflate objective fact with subjective opinion.

Now, as for whether “proprietary” automatically equals “bad”… that’s a matter for very strong subjective opinion.

#5 On April 14th, 2006 3:16 pm Dustin Diaz replied:

Ya gotta love comments on the wasp site now :) – indeed it helps conversations like these get out into the open.

Anyway, back to the matter. No doubt indeed that I’ve found Dan’s Builder to be quite useful and it keeps your structure looking real nice and readable. But on innerHTML. No, Jeremy, you didn’t say anything was wrong with it. As a matter of information, it’s cool to know now that the W3 is working on standardizing xmlHttpRequest. Do you suppose it’s possible to get in something like innerHTML? or rather, innerXML? It’s seems entirely too useful to just tag it as being ‘bad’ (and again, I know you didn’t say it was bad).

#6 On April 14th, 2006 3:51 pm innerHTML and DOM Methods replied:

[...] Keith on DOM Builder (Wasp) [...]

#7 On April 15th, 2006 5:27 pm Johnny Scrutchins replied:

Need to update my Internet. B
Browsen

#8 On April 16th, 2006 10:32 am Dan Webb replied:

I’m not too sure myself on what method is best to use from a practical point of view. I actually wrote the DOM Builder because I thought it was cleaner to deal with in a script compared to long strings full of quoted ” characters rather than the fact that it was necessarily better to use the DOM API over innerHTML. With DOM Builder, the code is even more compact than the HTML it generates. That’s it’s strongest point for me.

I actually toyed with the idea of having it build HTML strings rather than DOM nodes or maybe have it include the option to do either but that could bloat the script a bit. I’ll look into it.

Too me the only thing that stops me using the DOM API for everything is how slow IE’s implementation is.

#9 On April 18th, 2006 12:35 pm Chris Heilmann replied:

Dustin, the reason it is called innerHTML is that it is not innerXML, but an attribute that is only applicable in a browser and HTML environment. A lot of web standards go beyond this scope and rightfully so.

XML is a standard very much in use – outside the traditional web design world due to lack of browser support. There the DOM also applies and many .NET, JAVA or PHP programmers use the DOM methods defined in the W3C standards. Muddling these standards because of a speed issue with browsers would not really help.

That innerHTML can be the better solution for some applications and scenarios is not even a debate, it is a fact. However, it does not make it a standard and IMHO it does allow for sloppy coding. I cannot generate unclosed tags with the DOM, but I can write whatever I please inside innerHTML.

#10 On April 21st, 2006 12:24 pm Dave Bleeker replied:

Hi all,

I have to admit that the use of innerHTML method can save a lot of time and headache in some cases, but I agree with Chris Heilmann and I think the idea nothing is wrong with it is a mistake. Please correct me if I’m wrong, but basicly there are 2 major problems when using the innerHTML method:

1. All previously DOM nodes will be lost. Therefore you need to reinitialize them if any code depends on those nodes. Not really sophisticated in my opinion.

2. All content is rendered again, regardless whether the content was already rendered.

Therefore I think it is better to use the W3C compliant way of adding nodes to your document, and I wouldn’t recommend using innerHTML when it comes to scalabillity and OOP programming.

#11 On April 30th, 2006 5:25 am M. Gozler replied:

I made–and have been from time to time revising (fixing code)—what I call the ‘DOM1.js’ library of functions a long time ago to handle exactly that problem either of nonconformance to W3C “recommendations” (even they are not willing to declare them standards!—such as the MSIE abence of the document.createDocumentFragment() method, as well as to handle pseudo-methods such as making document fragments out of setting “properties” like .innerHTML.

Should anyone be interested in this library of functions, email me.

You are warned that these have only been barely tested by me, and they worked for my purposes.

The principal function “makeHTMLDocFrag(string)” takes a string of HTML-formatted code just like setting .innerHTML, and it returns a document fragment (except under IE, in which it returns the tree under a DIV root, I think). Moreover my functions do syntax/code checking: they check what elements can be contained inside and outside them, so that a legal document fragment is created.

#12 On June 19th, 2006 6:52 pm Garrett replied:

This set of functions is really only to address a small handful of IE specific DOM bugs.

innerHTML is faster and sometimes cleaner. It is sometimes more appropriate than using DOM creational methods.

createDocumentFragment is supported in IE.

#13 On July 29th, 2006 3:11 am lehman replied:

David, interesting concept, although it is a bit like putting the carriage before the horse. What DOM methods teach developers is to stop seeing the HTML page as a massive string but as a set of nodes.

#14 On September 22nd, 2006 7:08 am der_simon replied:

I’m writing on a substitute for innerHTML calles innerDOM. It just works on most strings you type in.
Some things are net yet implemted and have to be writen.

So see the script and test it: http://innerdom.sourceforge.net/

Der Simon

#15 On October 8th, 2006 8:36 pm Tony Blacker replied:

Thank you, been searching for ages for a concept such as this, very very helpful! Cheers.

#16 On January 27th, 2007 11:33 pm Charles Ulrich replied:

The links to the scripts return a 404…

Post a Reply

Comments are closed.