Bug 15522 - Add execCommand() to Element
Add execCommand() to Element
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: HTML Editing APIs
unspecified
All Windows 3.1
: P2 enhancement
: ---
Assigned To: Aryeh Gregor
HTML Editing APIs spec bugbot
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-11 16:10 UTC by Aryeh Gregor
Modified: 2013-02-20 19:32 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2012-01-11 16:10:46 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.