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

Re: Improving the DOM

From: Aryeh Gregor <ayg@aryeh.name>
Date: Wed, 9 Nov 2011 09:34:19 -0500
Message-ID: <CAKA+Axmh=rahsYLv27Aw+WBhba=XV+xG8KSdEhZirmx5VhUFLg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: www-dom@w3.org
On Tue, Nov 8, 2011 at 4:30 PM, Anne van Kesteren <annevk@opera.com> wrote:
> We introduce a DocumentContent union type (DOMString maps to a Text node):
> DOMString | CharacterData | Element | DocumentFragment

So this excludes Document and DocumentType.  Is there any reason to go
out of our way to exclude DocumentType here?  If someone wants to do


is there some specific reason it shouldn't work?  We should just make
it work with any Node, except of course Document.

> We introduce these methods on Element and DocumentFragment:
> prepend(DocumentContent... nodes)
> append(DocumentContent... nodes)
> We introduce these methods on Element, DocumentFragment, and CharacterData:
> before(DocumentContent... nodes)
> after(DocumentContent... nodes)
> We introduce this method on Element and CharacterData:
> replace(DocumentContent... nodes)
> We introduce this method on DocumentType, Element, and CharacterData:
> remove()

I would just put these on Node, and if they're called in some place
where they don't work, they throw.  This matches all the existing
methods, like insertBefore() and so on.  Why should we go to the
trouble of defining the same method on a bunch of different interfaces
instead of once on Node?  It's just a matter of whether it throws
TypeError or HierarchyRequestError, so let's make it simple to spec.

We definitely shouldn't leave them off of DocumentType just because we
wish it didn't exist.  That would make them not drop-in replacements
for insertBefore() et al., for no good reason I can see.

These should all return the context object.  That's a good pattern we
should be adopting.

Overall, though, I think this proposal is excellent.
Received on Wednesday, 9 November 2011 14:35:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC