Bugzilla – Bug 15522
Add execCommand() to Element
Last modified: 2013-02-20 19:32:58 UTC
Suggested by Ojan Vafai: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0090.html
I think we should expose it something like this:
* If the element does not have contenteditable set to true, throw. (This means we should also throw for the body of a document with designMode, unless that body also has contenteditable=true.)
* For things like styleWithCSS, set the flag for that editing host and its descendants only.
* For regular commands like bold, run the command restricted to the descendants of that editing host.
This solves the problem of clicking the B button next to one editing host and making text in another editing host bold, or styleWithCss etc. changes leaking between editing hosts. If we do this, I'd also be okay with adding new flags.
There are two important changes we'd need here, I think:
1) Make a concept of "editing flags" or something (not a good name; they might contain data, not just booleans). The document always has a value for each editing flag, and you can set them on an editing host too by calling execCommand() on it, but by default they're all set to "inherit" for non-document editing hosts. To get the editing flag for an element, go up the DOM until you hit something with the flag set. Then change things like "If the CSS styling flag is false:" to "If the CSS styling flag for node is false:".
2) Change things like "Let element list be all editable Elements effectively contained in the active range" to exclude anything outside the node you called execCommand() on.
While I'm at it, it might make sense to fix bug 13911.
This should be flagged prominently as a new unimplemented feature, so that implementers should be sure to critique the design if they don't completely like it.