Re: Some thoughts on DOM 2.0, Simpler

On Sun, 26 Jul 2009 23:39:09 -0400
Doug Schepers <schepers@w3.org> wrote:

> 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.
> 
> 
> [1] http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
> [2] http://dev.w3.org/SVG/proposals/api/svg2api.svg
> [3] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM

Sorry to jump in on this, but...

I just looked at [1] and I really like this idea. I've used a similar
interface for generating XML content (and SVG) in both Perl and Forth.

If the attributes are checked correctly for invalid attribute names,
this is a great way to create XML programatically. It's sometimes handy
to be able to construct the attribute object in stages and then make
one call to create the actual object at the end. It avoids the
"incomplete construction" issue with creating an element and then
setting the attributes one by one.

I've built utility methods to do this with some applications, but I've
never ended up generalizing it (for some reason).

As far as the nested objects issue is concerned, temporary objects are
an easy workaround. (Not a solution, but a workaround would still be
better than the current approach.)

G. Wade
-- 
If it doesn't have to be right, I can make it arbitrarily fast.
                                                    -- Rick Hoselton

Received on Monday, 27 July 2009 04:01:01 UTC