Comments on: DOM Builder

By: Charles Ulrich

Charles Ulrich — Sun, 28 Jan 2007 04:33:50 +0000

The links to the scripts return a 404…

By: Tony Blacker

Tony Blacker — Mon, 09 Oct 2006 01:36:19 +0000

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

By: der_simon

der_simon — Fri, 22 Sep 2006 12:08:05 +0000

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

By: lehman

lehman — Sat, 29 Jul 2006 08:11:38 +0000

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.

By: Garrett

Garrett — Mon, 19 Jun 2006 23:52:14 +0000

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.

By: M. Gozler

M. Gozler — Sun, 30 Apr 2006 10:25:59 +0000

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.

By: Dave Bleeker

Dave Bleeker — Fri, 21 Apr 2006 17:24:30 +0000

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.

By: Chris Heilmann

Chris Heilmann — Tue, 18 Apr 2006 17:35:16 +0000

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.

By: Dan Webb

Dan Webb — Sun, 16 Apr 2006 15:32:34 +0000

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.

By: Johnny Scrutchins

Johnny Scrutchins — Sat, 15 Apr 2006 22:27:46 +0000

Need to update my Internet. B
Browsen