Re: Improving the DOM; rev 2

These methods seem fine. I'd be a great addition to have this as sugar.

I'm all for returning the ContentNode your operating on as the return
value. It's easy to remember.

As for where restrictions should apply at the IDL or method definitions
seems like it should come down to performance concerns.

On Fri, Nov 18, 2011 at 1:02 PM, 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.
>
> 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/
>
>