- From: Jeff Schiller <codedread@gmail.com>
- Date: Fri, 20 Nov 2009 11:26:29 -0600
- To: www-svg <www-svg@w3.org>
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