Comments on: Magic DOM

By: ta

ta — Wed, 27 Jun 2007 21:48:48 +0000

Anyone tested this with the input element?
Just found that IE does not write the name attribute when created in runtime

By: gonchuki

gonchuki — Mon, 25 Jun 2007 14:34:31 +0000

innerHTML may lead to a broken DOM if injected code is erroneous.
using DOM building functions ensures DOM’s sanity and allows for extra functionality such as adding behaviours or setting properties to nodes.

By: Andi

Andi — Sat, 23 Jun 2007 17:41:27 +0000

@ Hans:
- Then a page loaded and build of xhtml will inpredictable, too. Because it’s parsed at runtime just like innerHTML.
- InnerHTML is a nice function that works in all browsers.
- Thats why I use the firstChild thing ;)

By: Francesco

Francesco — Sat, 23 Jun 2007 13:35:49 +0000

During the development of the first releases of PassPack, I adopted Easy DOM Creation by Michael Geary to quickly manage the DOM elements. But, with the beta4 version of PassPack I needed to overcome Michael’s library’s limits (due to the compatibility with Prototype). So I developed jQuick. It is at http://jquick.sullof.com

By: Hans Schmucker

Hans Schmucker — Sat, 23 Jun 2007 10:34:22 +0000

Because innerHTML is unpredictable, non-standard and doesn’t return references.

By: Andi

Andi — Sat, 23 Jun 2007 04:31:14 +0000

I still do this with simple innerHTML, to add handlers I grab elements by getElementsByClassName, $ or $$. Example:

var d = $(document.createElement(‘div’));
d.update(‘Equipments’);
return d.firstChild;

For me it’s the most consequent and natural way to create Element( tree)s. Why use third party libs in this case?

By: mozbeast

mozbeast — Fri, 22 Jun 2007 23:48:31 +0000

last i checked FlyDOM was 8x as long as my version and didnt support adding inline event handlers for the elements – once you start doing that with nested functions, lexical scoping and closures you can eliminate the use of selectors (and their inherent selection time) and fragile parent/subling/child traversals…

but the general concept is great. its too bad using an object literal for each DOM literal is more verbose than using an array..

By: Eric

Eric — Fri, 22 Jun 2007 17:34:25 +0000

I tend to use Dan’s DomBuilder, except when I have to build a lot of nodes. Used with MooTools (especially .adopt()), it makes some rather clear code. If something doesn’t run fast enough, I optimize afterwards by switching to .innerHTML changes.

By: Michael Geary

Michael Geary — Fri, 22 Jun 2007 17:13:02 +0000

There are sure a lot of these. Dan’s DomBuilder is great. There’s also my old DOM creator for jQuery and Prototype (which actually doesn’t depend on either library) from January 2006.

A comment in the Magic DOM post suggests an alternative syntax, which happens to be about the same as Olsow’s version that was posted as a comment to my DOM creator article a year ago. If you like that syntax, a more fully developed version is Ken Stanley’s FlyDOM for jQuery, which is now used at digg.com.

These days I don’t even use my own DOM creator much – instead I use good old innerHTML. Much faster!

By: Garrett

Garrett — Fri, 22 Jun 2007 16:54:55 +0000

@Jakob I think you're right. This seems to be a syntax error:

var dl = DL({'class': 'my_dl'}, var dt_equ = DT({'class': 'my_dt'}, 'Equipments'));


var dt_equ = DT({'class': 'my_dt'}, 'Equipments');
var dl = DL({'class': 'my_dl'}, dt_equ);

The first example posted by Ajaxian will have an error. It's a good example that shows how taking too many shortcuts can make the code less explicit, and lead to bugs, which are not easy to pinpoint. Jakob found it. DOM delegate. Adds more symbols to the global namespace by creating a series of functions which delegate to the DOM. The benefit is that it is shorter to use than the DOM. The drawbacks would be: decreased performance due to unnecessary delegate, less explicit, and harder to debug, adds more symbols to the global namespace, which could possibly create a problem.

By: gonchuki

gonchuki — Fri, 22 Jun 2007 16:13:05 +0000

only thing i don’t like is having those function names left in the wild of the global namespace.
It’s good to see people taking Mochikit’s codebase and working from it.

By: Andy

Andy — Fri, 22 Jun 2007 16:06:03 +0000

@Theo: It’s stand-alone and light-weight. Not everyone would include an entire library for one functionality.

By: Theo

Theo — Fri, 22 Jun 2007 15:33:54 +0000

Looks exactly like MochiKit.DOM, and just about all the other libraries… what does it offer that makes it more attractive than the existing libraries?

You can check out the HTMl/XML for JavaScript (http://www.ivy.fr/js/xml) that enables you to do the same things, but you can also generate markups for RSS, RDF, etc using a simple Python script.

By: Eduardo

Eduardo — Fri, 22 Jun 2007 13:08:34 +0000

Actually it does.
dt_equ is being passed as an argument to the DL() function.

By: Jakob Kruse

Jakob Kruse — Fri, 22 Jun 2007 12:18:00 +0000

The example seems to be missing something. Line 7 of the “original” adds ‘dt_equ’ as a child of ‘dl’. I would be very surprised if line 2 of the example also accomplishes this.

By: Dan Webb

Dan Webb — Fri, 22 Jun 2007 12:08:53 +0000

I wrote DomBuilder a while a go and this is almost identical except that it doesn’t include the cross browser attribute support (which renders this version pretty unusable to be honest). If you want this functionality I’d really recommend using DomBuilder:

http://svn.danwebb.net/external/DomBuilder/trunk/dombuilder.js

Comments on: Magic DOM

By: ta

By: gonchuki

By: Andi

By: Francesco

By: Hans Schmucker

By: Andi

By: mozbeast

By: Eric

By: Michael Geary

By: Garrett

By: gonchuki

By: Andy

By: Theo

By: SÃ©bastien Pierre

By: Eduardo

By: Jakob Kruse

By: Dan Webb