modifying the DOM WAS: Node append

Upon more thought, I've come to believe that we should add new methods that
just do what we want instead of trying to retrofit the old ones. The old
methods can continue to function on just nodes, avoiding any concerns of
killing the performance of existing sites and providing an opportunity for
performance optimizations for sites that really need it.

Specifically, lets add the following methods to Node:
prepend(nodeish) - Adds to the start of the node.
append(nodeish) - Adds to the end of the node.
before(nodeish) - Adds before the node.
after(nodeish) - Adds after the node.
replace(nodeish) - Replaces the node.
remove() - Removes the node.

I'm a bit on the fence about what the definition of a nodeish should be. I
see three options:

1. node, string, array, nodelist
2. node, string, array, nodelist, number, bool, undefined, null
3. node, string, anything with a length property is treated as an array,
anything else is toString'ed.

prepend(array/nodelist) would prepend all the items in the array/nodelist.
prepend(string) would create a text node with the string as it's value and
prepend that. prepend(number/bool/undefined/null) would prepend a text node
with the toString'ed value of the argument.

I'm fine with any of these three options, but I have a slight preference for
option 2. It allows for all the common use-cases, but leaves the door open
for future extensibility, e.g. maybe we'll want to have some special
behavior for Blobs in the future.

Ojan

On Mon, Oct 3, 2011 at 10:07 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Mon, 03 Oct 2011 19:01:19 +0200, Erik Arvidsson <arv@chromium.org>
> wrote:
>
>> On Sun, Oct 2, 2011 at 13:10, Aryeh Gregor <ayg@aryeh.name> wrote:
>>
>>> 4) It allows the argument to behave like a real string argument, with
>>> anything passed to it cast to a string, instead of throwing.
>>> JavaScript is weakly typed, and authors are not used to distinguishing
>>> much between 42 and "42".
>>>
>>
>> This one is important. JS devs are not used to do
>> alert(value.toString()) nor innerText = value.toString() (Yes, they
>> are unaware of textContent but that is a different problem).
>>
>> This point (and to be defined NodeList/Array support) prevents me from
>> jumping up and down celebrating.
>>
>
> We can make that work. Web IDL introduced [AllowAny] for it, but maybe that
> should simply be the default. XMLHttpRequest.send() does that. It accepts
> everything, some objects behave special, but everything else will be
> stringified.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>