Re: Some thoughts on DOM 2.0, Simpler

Hi, Jonathan-

Jonathan Watt wrote (on 7/27/09 7:11 AM):
> 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.

Okay, I've clarified the front matter to clarify that this is still 
speculative, and where people can find our other ideas.

It would be a bit sad if people took anything on our wiki as anything 
but tentative, given that it's not even an Editor's Draft, much less a 
Working Draft.


> 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.

It's all the way down at the bottom, as a comment.  Maybe it needs to be 
more prominent.

> 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.

Yes, I chatted briefly with Cameron about that, but we didn't come up 
with anything.



>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.

That sounds like an interesting idea.


I wonder if we could define a set of interfaces that only work in 
ECMAScript.  All the same functionality will be available for Java, even 
if in the older, more verbose manner, and since we are trying to 
optimize for the browser with this API, I would like to be able to take 
advantage of JavaScript's facilities.


> 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 made an somewhat arbitrary choice for my toy proof-of-concept, and 
specified it that way.  The logic behind it was that I went for the less 
"lossy" and more "portable" of the options.  I figured that the author 
could more easily process the object if it had names, or immediately 
reuse it on another element, or send it somewhere else pass it somewhere 
anonymously and have it processed logically there.  The option of 
getting the attribute values back in the order specified seemed less 
compelling, and could be simulated by simply getting the object values 
by name in the desired order.


> 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.

I don't mind about the names.  I thought set/getAttributes was too close 
to set/getAttribute and might be more easily confused, but I don't 
really care what they're called (well, not much, anyway).


> 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".

Makes sense.  Again, I don't mind about the method names, but I wouldn't 
want to reuse the method name "createElement", even if it is on a 
different object.  It doesn't have the same syntax, which I think 
authors would find confusing.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 28 July 2009 12:24:36 UTC