Re: Some thoughts on DOM 2.0, Simpler

On 7/27/09 5:39 AM, Doug Schepers wrote:
> Jeff Schiller wrote (on 7/26/09 11:21 PM):
>> Speaking of creating child elements, I saw mention of a way to create
>> and automatically insert an element in the DOM.  While this might seem
>> good, if I wanted to create an animated Rect I'd probably have to
>> create and insert the rect first, then create and insert the various
>> animate child elements.  Each of these insertions into the DOM would
>> take extra time.  Also, wouldn't they cause mutation events to fire or
>> something?
>>
>> Seems like it's better to allow the author to create his subtree all
>> in JS and then push into the DOM with one call.
> 
> Actually, I'm not certain if you save any time by constructing a DOM 
> tree and dumping it in all at once (but I could be wrong).  It would 
> save on mutation events, though.

It can save a lot, even if mutation events are not in the picture.

> I do see your use case, and have updated the wiki [1] 

When I originally added this stuff to [3] I didn't consider it to be ready to be
broken out into a proposal. It was just another item in the "brain fart" list
from my POV, with unresolved issues that may make at least some of it unworkable
(I haven't gotten input from anyone else at Mozilla yet, but I see issues).
While we still have fundamental unresolved issues of our own, the page should
err on the side of "this is a brain fart" than "this is a proposal" IMO. Maybe
even just s/proposal/draft proposal/ would be enough.

One thing I noted in my original text is that this is pretty much ECMAScript
only as it stands, but that seems to have been lost in the move to its own page.
That's a big issue I think. DOM interfaces like Element are fairly language
agnostic since they're defined in IDL. Passing in an object literal to the
method you renamed to setAttrValues isn't really compatible with that, and I'm
not sure how or if we can define that to work in some way with strongly typed
languages such as Java. Thinking on the spot, perhaps we can define a
"PropertyBag" interface, and say in the ECMAScript Bindings doc that JS object
literals can be passed in to methods that expect an object to be of this type,
but this issue needs to be figured out one way or another.

The original text I wrote for the method you've renamed to getAttrValues
mentioned that returning an Array may be better than returning an object
litteral, since that would allow authors to get values back in the same order as
the order of the attribute names they specified in the input Array. Any reason
for removing that text? It's not obvious to me which return type is preferable.

I'm not sure I like the names setAttrValues and getAttrValues btw. I prefer
set/getAttributes as I originally had it. The "Values" seems at odds with
current method naming.

While on the issue of naming, I also preferred Element.createChild and
Element.createElement as I originally had it (to Element.insertElement and
Element.constructElement). I prefer "create" to "construct" since that's more
consistent with existing DOM methods, and I'd like the naming of the two methods
to be closely related to remind people that they both do exactly the same thing,
except one inserts the new element as a child, and the other does not. Hence
"create child" vs "create element".

Jonathan

> and my prototype 
> implementation [2].
> 
> However, I will note that since SVG is so attribute-heavy, many if not 
> most elements will not require child content, especially if you aren't 
> using SMIL, so I think the insertion constructors are still extremely 
> useful, so I've kept them in.
> 
> I'm also interested to hear feedback about our more general thoughts and 
> ideas [3], especially from implementers.
> 
> 
> [1] http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
> [2] http://dev.w3.org/SVG/proposals/api/svg2api.svg
> [3] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
> 
>

Received on Monday, 27 July 2009 11:12:05 UTC