Re: More Ideas around DOM Constructors

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