[whatwg] Request for new DOM property textarea.selectionText

Sun Apr 29 00:33:08 PDT 2012

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
>
>