W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: Improving the DOM; rev 2

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 18 Nov 2011 11:02:19 -0800
Message-ID: <CANMdWTthUupo=Da4AVKaviFUgvjz=A-sOWEQ3gE9Smh7uOJ=SA@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Fri, Nov 18, 2011 at 10:20 AM, Ojan Vafai <ojan@chromium.org> wrote:

> On Fri, Nov 18, 2011 at 5:02 AM, Anne van Kesteren <annevk@opera.com>wrote:
>
>> Before: http://lists.w3.org/Archives/**Public/www-dom/2011OctDec/**
>> 0140.html<http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0140.html>
>>
>> I forgot to explain before that we do not want to expose these methods
>> where they do not make sense. The current DOM has that, but I do no think
>> that is a particularly good design, and it is not a design we have used
>> elsewhere in the platform. Java and its casts are not a concern for the
>> platform.
>>
>> It seems however people do not want to restrict these methods so far you
>> get limitations. Taking that into account I think this is the API you end
>> up with:
>>
>> union ContentNode = DOMString Node;
>>
>> Document / DocumentFragment / Element
>>
>> prepend(ContentNode...)
>> append(ContentNode...)
>>
>> DocumentType / Element / CharacterData
>>
>> before(ContentNode...)
>> after(ContentNode...)
>> replace(ContentNode...)
>> remove(ContentNode...)
>>
>> The next question is whether we should impose restrictions on these
>> methods at the IDL or method implementation level. E.g. appending a
>> DocumentType to Document can be fine, but appending it to Element is never
>> fine. Also currently you know that appendChild(DocumentFragment) on an
>> Element is going to work. With these vararg methods you do not, unless the
>> arguments are restricted at the IDL level, or otherwise at the method
>> implementation level. I no longer feel strongly where we do this, but I
>> believe Ojan had some concerns with respect to performance.
>>
>
> Sorry, I never responded to this on the other thread. This is not a purity
> concern. It's a performance vs. simplicity tradeoff.
>
> Every check we need to do slows down the ultimate performance we can get
> out of these functions. The current appendChild/etc methods all have to do
> a bunch of special checks for Document and DocumentType. We could do away
> with some of these if we didn't support these methods. It wouldn't be a
> huge performance gain, but even small gains are worth it for these methods,
> which are often in the critical path of user-visible operations.
>
> The only use-case for having these methods on DocumentType and Document is
> so that you can pass any node to a generic DOM walker and have it be able
> to call these methods. I don't think this is valuable in practice. For
> example, calling before/after/remove/replace on a DocumentType will almost
> always throw an exception anyways due to the rules of what root elements a
> Document can have, same with calling append/prepend on Documents.
>
> The obscure, albeit legitimate cases where you might want to call these
> methods on DocumentType/Document are not worth any performance cost for
> such performance-critical methods.
>

Ugh. I took a closer look at WebKit's code here and everything I said above
WRT performance is just wrong. My memory of what we do was off. With that,
I'm happy with the API as presented here. Sorry for the noise.
Received on Friday, 18 November 2011 19:03:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT