- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Wed, 9 Nov 2011 09:34:19 -0500
- 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 document.doctype.remove(); document.prepend(newDoctype); 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