- From: Jeff Schiller <codedread@gmail.com>
- Date: Wed, 25 Nov 2009 13:03:12 -0600
- To: www-svg <www-svg@w3.org>
Is there a proposal on how to handle attributes in different namespaces with DOM Constructors? If we specify a property bag is it ok to just do: { fill: "red", "xlink:href", "foo.html" } ? As long as xlink: lines up with a declared namespace prefix? Or perhaps the reliance on the XLink namespace is going away ? Jeff On Fri, Nov 20, 2009 at 11:26 AM, Jeff Schiller <codedread@gmail.com> wrote: > 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 Wednesday, 25 November 2009 19:03:46 UTC