- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Mon, 29 Aug 2011 14:57:07 -0400
- To: W3C WebApps WG <public-webapps@w3.org>
- Cc: Ryosuke Niwa <rniwa@webkit.org>, Ehsan Akhgari <ehsan@mozilla.com>
In editing, it's common to want to change an element's name. For instance, document.execCommand("formatblock", false, "h1") will change the current line's wrapper to an <h1>. Unbolding <b id=foo> should produce <span id=foo>. My editing spec defines an algorithm for this <http://aryeh.name/spec/editing/editing.html#set-the-tag-name> which is used in a bunch of places. The thing is, one requirement for editing is that you want to preserve the user's selection. Real-world use-case: some editors want to produce <strong> instead of <b> for bold. One way to do this is to let the browser create <b> tags via the bold command, then iterate through them all and change them to <strong>. But this will involve removing the <b> element from the DOM, and if the selection was inside it, it will now be collapsed outside it. There's no way for the author to avoid this except manually saving and restoring the selection with fixups. And that won't work either for ranges other than the selection. We can't actually change the tag name of the node in place, because then it will have to implement a different interface in general. But we could have a setTagName() method that creates a new Element with the given tag name, moves the children, copies the attributes, puts it in the right place, fixes up the Ranges, then returns the newly-created Element. Does this seem reasonable to anyone, or is it too confusing that the object will be different?
Received on Monday, 29 August 2011 18:57:56 UTC