W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: new DOM4 insertions methods and return values

From: Jake Verbaten <raynos2@gmail.com>
Date: Wed, 16 Jan 2013 02:32:18 -0800
Message-ID: <CAMCMjp3vF=dnTtuydn5thaTaR3227vZbFMf7jhcambVdJCRMKQ@mail.gmail.com>
To: Ms2ger <ms2ger@gmail.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Wed, Jan 16, 2013 at 1:57 AM, Ms2ger <ms2ger@gmail.com> wrote:

> On 01/16/2013 02:52 AM, Jake Verbaten wrote:
>> The older DOM mutation methods like
>> Node appendChild(Node node);
>> returned the node you inserted
>> The newer DOM mutation methods like
>> void append((Node or DOMString)... nodes);
>> return void instead.
>> It would be useful if append returned either the single node or a
>> DocumentFragment
> The DocumentFragment option seems somewhat difficult to implement;
> wouldn't it require the nodes passed to append() to be children of the
> newly created DocumentFragment, as well as the node append() was called on?
> What should parentNode return on those nodes?

I actually meant the value returned would be the result of the mutation
macro ( http://dom.spec.whatwg.org/#mutation-method-macro ) which is either
null for no nodes, a single node, or the document fragment that's created.

That document fragment when passed back to me as a result would actually
have no children because in the process appending the document fragment to
the parent container the nodes have been removed.

The only reason to pass the document fragment back is to match what
elem.appendChild(documentFragment) does currently and to have the result be
either null or a single type. In reality it might make more sense to return
the first node in nodes or the nodes as an array.

> Thanks
> Ms2ger
Received on Wednesday, 16 January 2013 10:32:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC