Re: Improving the DOM

I think .before, .after and .remove should be available on all nodes
which can appear in the normal document tree, including PIs and
DocTypes. There's no reason to be inconsistent here and it'll just
make it annoying for people that are iterating over the tree and
perform operations on it. I agree that DocTypes/PIs aren't commonly
used, but they do appear in the DOM now and then and it makes it even
worse for authors if they have to explicitly handle those types of
nodes different.

As for .append and .prepend, I think we should make those exist on all
nodes which can have children, including Documents. This for the same
reason, it makes things more consistent for authors.

I don't think it's our job to pass judgement on what nodes people
should or should not be modifying or having in their DOM.

/ Jonas

On Tue, Nov 8, 2011 at 5:02 PM, Ojan Vafai <ojan@chromium.org> wrote:
> I'm very happy with this. To summarize, append/prepend are on
> Element+DocumentFragment and all the other methods are on
> Element+CharacterData.
> Anne, pointed out on #whatwg that Comment and ProcessingInstruction can
> appear as children of the Document, so we'd have to check the parent and
> throw, e.g. if you call replace on a comment that is the child of the
> Document with a DocType. That kind of sucks, but I don't see that putting
> all these methods on Element+TextNode would be better. I'd prefer that if we
> could get away with it, but I think we probably can't because then a simple
> for-loop removing all the children of a node would need to make sure they
> have a remove method first.
> Ojan
> On Tue, Nov 8, 2011 at 2:37 PM, Anne van Kesteren <annevk@opera.com> wrote:
>>
>> On Tue, 08 Nov 2011 16:22:32 -0700, Jake Verbaten <raynos2@gmail.com>
>> wrote:
>>>
>>> On Tue, Nov 8, 2011 at 9:30 PM, Anne van Kesteren <annevk@opera.com>
>>> wrote:
>>>>
>>>> We introduce these methods on Element, DocumentFragment, and
>>>> CharacterData:
>>>
>>>> before(DocumentContent... nodes)
>>>> after(DocumentContent... nodes)
>>>
>>> What does DocumentFragment before and after do?
>>
>> Good point, they should not be on DocumentFragment.
>>
>>
>>>> We introduce this method on Element and CharacterData:
>>>>
>>>> replace(DocumentContent... nodes)
>>>>
>>>> We introduce this method on DocumentType, Element, and CharacterData:
>>>>
>>>> remove()
>>>
>>> Why can we remove a DocumentType but not do anything else with it? That
>>> makes the API anti symmetrical to me
>>
>> Yeah, lets not introduce it on DocumentType. People should not be using
>> DocumentType anyway.
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>>
>
>

Received on Wednesday, 9 November 2011 01:19:58 UTC