Re: Some thoughts on DOM 2.0, Simpler

Hi, Jeff-

Jeff Schiller wrote (on 7/26/09 11:21 PM):
> As a developer, I'd be very much in favor of an E4X-like or
> innerHTML-like solution to
> creating elements (as evidenced by my DOMParser hack earlier on the mailing
> list).  JSON also feels like a hack and (as mentioned on the wiki)
> creating nested elements would be painful and bring back shades of
> LISP-like brace counting.  In general I hate having to create
> languages using other language/syntax (PHP to create HTML/SVG is
> another example of this).

Okay.  If you have any concrete proposals, it would be great to hear them.

> Speaking of creating child elements, I saw mention of a way to create
> and automatically insert an element in the DOM.  While this might seem
> good, if I wanted to create an animated Rect I'd probably have to
> create and insert the rect first, then create and insert the various
> animate child elements.  Each of these insertions into the DOM would
> take extra time.  Also, wouldn't they cause mutation events to fire or
> something?
> Seems like it's better to allow the author to create his subtree all
> in JS and then push into the DOM with one call.

Actually, I'm not certain if you save any time by constructing a DOM 
tree and dumping it in all at once (but I could be wrong).  It would 
save on mutation events, though.

I do see your use case, and have updated the wiki [1] and my prototype 
implementation [2].

However, I will note that since SVG is so attribute-heavy, many if not 
most elements will not require child content, especially if you aren't 
using SMIL, so I think the insertion constructors are still extremely 
useful, so I've kept them in.

I'm also interested to hear feedback about our more general thoughts and 
ideas [3], especially from implementers.


-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 27 July 2009 03:39:18 UTC