Re: Improving the DOM; rev 2

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.

As to what these methods return, we should probably go with chaining. I'm
> not a big fan, but it seems to be what all the cool kids are doing these
> days, and the cost is negligible.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>