Re: More Ideas around DOM Constructors

My apologies, I missed
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Constructors_for_Elements

I really think that providing a constructor for each element type is a
bad idea.  I also think providing attributes in the constructor
signature is a bad idea.

I also missed http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#createChildNS
which seems to be inline with my thinking though it is adding new
methods on Element apparently.

I still think just adding a new (optional) argument to the standard
DOM methods is the right approach there - it's what people are
familiar with.

I also think innerMarkup is fine too if there is potential confusion
around innerHTML in a SVG context.

Regards,
Jeff

On Fri, Nov 20, 2009 at 11:17 AM, Jeff Schiller <codedread@gmail.com> wrote:
> 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:27:02 UTC