More Ideas around DOM Constructors

First off, I assume the SVG WG wiki at
http://www.w3.org/Graphics/SVG/WG/wiki/ is for WG members only?  If
not, maybe I had an account before but lost the login info.  I tried
to login via OpenID but it says that the pages are locked.

Anyway, I was reading
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM/JSON_Constructors.

I was also reading
http://www.slideshare.net/jaffathecake/optimising-where-it-hurts-jake-archibald
yesterday.

Anyway, here are my thoughts on constructors.  I'll say up front that
I'm not familiar with the WebIDL stuff that jwatt has mentioned
several times, so my apologies if that has an impact on the following.


There are a variety of ways that DOM elements can be constructed.  In
HTML land, there are pretty much two ways:  DOM Level 1 and
innserHTML.  It seems that many browsers (IE, Mozilla, Opera) have
optimized using innerHTML, though it's interesting that Webkit
browsers actually suffer from innerHTML manipulation (see slide 84 of
the above pack).

In SVG currently there is only the DOM createElement, setAttribute,
appendChild route at the moment.

Not only is it very painful for users, but it's probably slower in
Mozilla, Opera than it could be because there are (N+2) DOM calls you
need to make to get the node into the DOM, where N = number of
attributes you want to set.

On the other hand innerHTML has to take a JS string and parse it to
create DOM elements, then attach the elements.  At some point, this
must have an advantage in the case where you need to create a
large-ish subtree of elements.  In other words, I'm not sure how well
the chart on slide 84 would hold up if they had constructed large
trees of nodes using DOM and then innerHTML and compared the two.

Here is my proposal, they are rather simple:

1) Extend createElement(), createElementNS() with a new argument.
This new argument should be a name-value map of attributes.  In JS
this would look like:

createElement("circle", {cx: 40, cy:40, r:20, fill:"red"})

As before, this returns the element, which you could then
appendChild/insertBefore, etc.

This reduces the number of DOM calls by N.  It's actually fairly
readable in my opinion and doesn't suffer from the order problem that
jwatt mentions on the DOM wiki because we're only talking about
attributes of a single element.

I'm not sure if language bindings are a problem here.  I really feel
that if a language does not provide a non-ordered name-value map then
it's not worth considering using these days (C++ std::map, Java Maps,
Python dictionaries, etc), but I'm really interested in hearing about
this from the WG.

2) For large-ish subtrees of DOM elements that need be created, the
solution seems obvious to me:  Adopt the innerHTML property from HTML5
for XML: http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml1
including the algorithm for setting the contents.

Personally, I don't think worrying about 'HTML' in the name of the
property matters these days, do you?

Regards,
Jeff Schiller

Received on Friday, 20 November 2009 17:18:08 UTC