This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Discussion: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1088.html DOM 3 Core defined a renameNode() method that no one implemented. Ehsan, Ryosuke, and I agreed at our face-to-face meeting that such a thing would be useful for editing. Dimitri said in that thread that he thinks it would be useful for Component Model. The existing definition leaves too many things undefined, though, and has other bad traits (like sometimes replacing the node and sometimes not, and being on Document instead of Element). Things it should do: * Should be a method on Element, probably called renameElement() or just rename(). * For consistency/completeness, probably should take a single argument that's the new name, which will be lowercased for HTML documents, and have a rename(Element)NS() variant. * Always make a new element with the desired name. Don't ever leave the existing one in place. * Copy all DOM attributes, event listeners, and custom JS properties that were stuck on the object. * Move all range endpoints appropriately. (This can be left to DOM Range as long as it's not yet merged into Core.) * Stick the new node next to the old one, move all the children, then remove the old one. * Return the new node. This is pretty nontrivial for authors to get right, and on some points impossible in general (like updating all range endpoints), so it seems like a good thing for browsers to implement.
What's the use case for changing the namespace?
> * Copy all DOM attributes, event listeners, and custom JS properties that were stuck on the object. By DOM attributes I assume you mean what HTML calls content attributes (as opposed to IDL attributes). For event listeners, it means registering new listeners for the new element. Should the listeners for the old element be removed? What about onfoo event handlers as IDL attributes? What about body and frameset onfoo that are reflected on window? How do you copy the custom JS properties? Enumerate and check hasOwnProperty? Call getters?
So how should the renaming work in cases like var el = document.createElement("input"); el.value = "foo"; el.rename("div"); el.rename("input"); alert(el.value); // what would be the value? The are of course many other similar cases. And, apparently rename is really a form of clone + move some data, so the method shouldn't be called rename()
(In reply to comment #1) > What's the use case for changing the namespace? Nothing. Just consistency with other methods. (In reply to comment #2) > By DOM attributes I assume you mean what HTML calls content attributes (as > opposed to IDL attributes). Yes. > For event listeners, it means registering new listeners for the new element. > Should the listeners for the old element be removed? What about onfoo event > handlers as IDL attributes? What about body and frameset onfoo that are > reflected on window? > > How do you copy the custom JS properties? Enumerate and check hasOwnProperty? > Call getters? (In reply to comment #3) > So how should the renaming work in cases like > > var el = document.createElement("input"); > el.value = "foo"; > el.rename("div"); > el.rename("input"); > alert(el.value); // what would be the value? > > The are of course many other similar cases. Fun questions! Doesn't really matter, we just need some behavior or other that's well-defined in all cases and does what we want in typical cases. > And, apparently rename is really a form of clone + move some data, so > the method shouldn't be called rename() Any suggestions?
(In reply to comment #4) > (In reply to comment #1) > > What's the use case for changing the namespace? > > Nothing. Just consistency with other methods. Then I suggest we wait with the NS method until a concrete use case arises. > Fun questions! Doesn't really matter, we just need some behavior or other > that's well-defined in all cases and does what we want in typical cases. How about copying the same things that cloneNode copies? (Except element-specific flags like script's "already started" flag which wouldn't make sense on any other element.)
I think you do not want to run the clone node steps defined by other specifications. <input> elements can be cloned with their associated value, but if you rename an <input> to a <div> it does not make sense that the <div> suddenly has the associated value concept only <input> elements have. Cloning does not cover event listeners however or custom JS properties. Custom JS properties seems problematic if they conflict with IDL attributes on the new object. Event handlers are problematic if they are not exposed on the new element. Event listeners can work, but is it worth it?
I'm leaning towards only using the semantics of cloning with Element.renameElement(localName) as API. (Using the somewhat longer renameElement to prevent clashes.)
This would *mostly* be a convenience API. But not completely, since restoring the selection faithfully isn't possible today. I think maybe we should look into making it possible to restore the selection faithfully without tying that ability to a convenience API.
As discussed on IRC, I think renameElement is misleading, because the API would not do any renaming but some sort of cloning. And moving event listeners would be quite error prone since it would mean that the expected 'this' of the event listeners would change. Other suggested methods names were substituteElement, morph, and most importantly replaceWithANewElementAndTransferAttributesAndStuff :) If we want this functionality, I think substituteElement might be good enough. But, I agree with Simon that perhaps we should look at other ways to move range/selection.
(In reply to comment #8) > This would *mostly* be a convenience API. But not completely, since restoring > the selection faithfully isn't possible today. I think maybe we should look > into making it possible to restore the selection faithfully without tying that > ability to a convenience API. That's a reasonable alternative. You could restore the selection faithfully today, but you can't restore other ranges. Still, the behavior is useful and enough and nontrivial enough to get right that it might be worthwhile anyway. (In reply to comment #9) > If we want this functionality, I think substituteElement might be good enough. That sounds like a good name, if we do this.
I tend to agree with the sentiment that its the selection restoration functionality that is really desired. As far as names for this new thing, I should remind folks that IE has: swapNode (http://msdn.microsoft.com/en-us/library/ms536774(v=vs.85).aspx), yet no one has *ever* to my knowledge asked that this be standardized. To me that translates to "not useful" in the web platform.
Bug 19007 appears to be such a request ;-) I'm not planning fixing on either that or this bug for now though.
I'm going to WONTFIX the idea of renameNode(). We will consider swap() separately per the bug mentioned above. Once somebody in the platform fancies working on text editing again we can think about making that better again too with a fresh perspective.