- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Sun, 29 Apr 2012 00:33:08 -0700
FYI, those commands listed below with enabledInEditableText (as supposed to enabledInRichlyEditableText) are ones available in input/textarea for WebKit: http://trac.webkit.org/browser/trunk/Source/WebCore/editing/EditorCommand.cpp?rev=113031#L1442 On Sun, Apr 29, 2012 at 12:29 AM, Ryosuke Niwa <rniwa at webkit.org> wrote: > On Sat, Apr 28, 2012 at 11:37 PM, Aryeh Gregor <ayg at aryeh.name> wrote: > >> On Sun, Apr 29, 2012 at 9:09 AM, Maciej Stachowiak <mjs at apple.com> wrote: >> > Does this work in any non-WebKit browsers? (Asking mainly out of >> curiosity; I would tend to agree in any case that adding nontrivial editing >> APIs that are specific to only plaintext editable controls is not a good >> idea. But it might be nice to specify explicitly whether execCommand works >> on form controls.) >> >> Test-case: >> >> data:text/html,<!DOCTYPE html> >> <input value=abc> >> <script> >> var input = document.body.firstChild; >> input.selectionStart = 1; >> input.selectionEnd = 2; >> document.execCommand("delete"); >> </script> >> >> This works in IE 10 Developer Preview and Chrome 20 dev, but not >> Firefox 15.0a1 or Opera Next 12.00 alpha. > > > Thank you for the data points. > > Particularly since WebKit's insertText only >> works on the current selection, and it's not as easy as it should be >> to save and restore the selection, so an API that can deal with >> arbitrary ranges directly is valuable. >> > > That sounds like a tangential issue. We can easily extend execCommand to > support arbitrary range(s) since such a feature is also valuable in richly > editable areas. > > > 3) It's not clear that all of the different selection modes of this >> function have use cases. >> >> In particular, the fourth argument's effect seems trivial to replicate >> using .selectionStart and .selectionEnd, so why is it worth the extra >> API surface area? >> > > Right. In general, I'm against adding new APIs unless there is a > compelling reason to do so. > > In this case, we have an API, namely document.execCommand, supported by > two major browser engines (for years) that provides more or less the same > functionality as the proposed API. > > - Ryosuke > >
Received on Sunday, 29 April 2012 00:33:08 UTC