Re: Improving the DOM; rev 2

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.