- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 30 Aug 2011 10:44:27 +0200
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Aryeh Gregor <ayg@aryeh.name>, W3C WebApps WG <public-webapps@w3.org>, Ryosuke Niwa <rniwa@webkit.org>, Ehsan Akhgari <ehsan@mozilla.com>
On Aug 29, 2011, at 23:29 , Dimitri Glazkov wrote:
> Document.renameNode seems cool. Aside from the awkward user data
> event, it matches perfectly the needs of the Component Model (updated
> to reference it here:
> http://wiki.whatwg.org/wiki/Component_Model#Performance).
>
> I am curious why no one had implemented this. We should dust it off,
> add a normal event to it, and set it sail.
Well, the specification for renameNode is more or less: "you should do something that, you know, sort of removes the node, unless you don't want to which is also, you know, okay". Just with a quick scan:
• sometimes you can rename the document element, sometimes you can't;
• might change the name and return the same node, but sometimes it might return a different one;
• depending on the above, it's unclear whether or not you get the same mutation events depending on whether it's the same node being renamed or a new one being created;
• defaulted attributes for the new element/new name may or may not be added.
That's not very friendly, to say the least. For reasons I don't quite understand this is also a method of Document when it would make much more sense on Element (we can forget about Attr). All in all, I think we'd be doing ourselves a favour by deprecating renameNode() and specifying a new one.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 30 August 2011 08:44:52 UTC