This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the editing spec defines that something is editable when the following is true[1]: > Something is editable if it is a node; it is not an editing host; > it does not have a contenteditable attribute set to the false state; > its parent is an editing host or editable; and either it is an HTML > element, or it is an svg or math element, or it is not an Element > and its parent is an HTML element. I think this should be expanded to include HTML form fields that can accept text input. This is already the behaviour in Chrome and Internet Explorer for some commands, though Firefox throws an error[2]. Although the majority of formatting commands might be useless, insertText, delete and forwardDelete could be useful for JavaScript based IMEs/virtual keyboards, along with cut, copy, paste, undo, redo and selectAll from the miscellaneous commands. There's also a use case for editors that switch between a designmode enabled iframe for formatted editing and a text area for raw editing - these editors would be able to reuse a lot of the same very short code (especially in the case of "insertText") without having to slice, concat and set the element values. [1]: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1027560
Ideally this will follow one way or another when these are defined as isolated shadow trees rather than "magical" elements.
I think of the list of commands that you mentioned, only cut, copy, paste, undo and redo will be useful. The rest can be polyfilled on top of the existing APIs. And AFAIK different browsers have different undo/redo queues (either per document or per form control), and there are security concerns with providing clipboard access without user intervention... With that in mind, is execCommand really the right API to expose to these elements? If we really want parts of the above functionality, why not just expose those as new APIs on HTMLInput/TextAreaElement?
(In reply to Ehsan Akhgari [:ehsan] from comment #2) > I think of the list of commands that you mentioned, only cut, copy, paste, > undo and redo will be useful. The rest can be polyfilled on top of the > existing APIs. insertText cannot easily be polyfilled against a HTML5 conforming browser for some input types, because .value may not match what the user sees in the input box and .selectionStart, .selectionEnd and .setRangeText() are wired up to throw if used. > And AFAIK different browsers have different undo/redo queues (either > per document or per form control), and there are security concerns > with providing clipboard access without user intervention... IIRC, users can grant clipboard access in most modern browsers, and the browser can still manage separate undo/redo queues, I don't really see how this would affect that. > With that in mind, is execCommand really the right API to expose to these > elements? If we really want parts of the above functionality, why not just > expose those as new APIs on HTMLInput/TextAreaElement? Should we really be creating new APIs where existing APIs might be able to do the job with only a minimal change? If Anne is correct, such a change to the existing wording might not be required anyway, only a change in implementation of the browsers that don't already support this.
(In reply to Andy Earnshaw from comment #3) > (In reply to Ehsan Akhgari [:ehsan] from comment #2) > > I think of the list of commands that you mentioned, only cut, copy, paste, > > undo and redo will be useful. The rest can be polyfilled on top of the > > existing APIs. > > insertText cannot easily be polyfilled against a HTML5 conforming browser > for some input types, because .value may not match what the user sees in the > input box and .selectionStart, .selectionEnd and .setRangeText() are wired > up to throw if used. Hmm, yeah, you're right! > > And AFAIK different browsers have different undo/redo queues (either > > per document or per form control), and there are security concerns > > with providing clipboard access without user intervention... > > IIRC, users can grant clipboard access in most modern browsers Hmm can you please give examples on that? I know that this is not possible in Firefox, but my memory on what other UAs do may be dusty. > and the > browser can still manage separate undo/redo queues, I don't really see how > this would affect that. The issue is, if we allow these operations, then we need to specify which undo/redo queue they will manipulate. Which is going to force the UAs that don't have the behavior that is specified to change their user facing behavior here. Which is fine, except that I don't think there is any consensus on which behavior (having a global undo/redo queue versus a per-control one) gives a better user experience. > > With that in mind, is execCommand really the right API to expose to these > > elements? If we really want parts of the above functionality, why not just > > expose those as new APIs on HTMLInput/TextAreaElement? > Should we really be creating new APIs where existing APIs might be able to > do the job with only a minimal change? If Anne is correct, such a change to > the existing wording might not be required anyway, only a change in > implementation of the browsers that don't already support this. Well, execCommand is not really an existing API here, as it's currently only defined on document. Even with the definition of these elements in shadow DOM, unless we have something like bug 14554, the execCommand API is not really relevant.
Sounds good to me, but be aware that the spec is not currently maintained, so it's not likely to change anytime soon. (In reply to Ehsan Akhgari [:ehsan] from comment #4) > (In reply to Andy Earnshaw from comment #3) > > insertText cannot easily be polyfilled against a HTML5 conforming browser > > for some input types, because .value may not match what the user sees in the > > input box and .selectionStart, .selectionEnd and .setRangeText() are wired > > up to throw if used. > > Hmm, yeah, you're right! The same goes for all of these: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements They're defined to be the same as certain user actions that are not exposed in any other way. > > IIRC, users can grant clipboard access in most modern browsers > > Hmm can you please give examples on that? I know that this is not possible > in Firefox, but my memory on what other UAs do may be dusty. IIRC, IE has a prompt. I don't think other browsers allow anything, but I could be wrong. > Well, execCommand is not really an existing API here, as it's currently only > defined on document. Even with the definition of these elements in shadow > DOM, unless we have something like bug 14554, the execCommand API is not > really relevant. Why shouldn't it work the same as with contenteditable, and operate on the focused element? If I focus a textarea and call document.execCommand("insertparagraph"), I don't see why it shouldn't work.
(In reply to Aryeh Gregor from comment #5) > Sounds good to me, but be aware that the spec is not currently maintained, > so it's not likely to change anytime soon. Fair enough. > IIRC, IE has a prompt. I don't think other browsers allow anything, but I > could be wrong. Yeah, I was mistaken, it's just IE. It's not something I've used for a long time :-)
(In reply to Aryeh Gregor from comment #5) > > Well, execCommand is not really an existing API here, as it's currently only > > defined on document. Even with the definition of these elements in shadow > > DOM, unless we have something like bug 14554, the execCommand API is not > > really relevant. > > Why shouldn't it work the same as with contenteditable, and operate on the > focused element? If I focus a textarea and call > document.execCommand("insertparagraph"), I don't see why it shouldn't work. Because we cannot implement any of the effects of the insertparagraph command in other contexts: <https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command>. At least not until textarea has a shadow DOM.
Well, yes, we'd have to define what insertParagraph does for textareas -- it should be the same as hitting Enter. But there's no reason I see that it shouldn't work.