[whatwg] Request for new DOM property textarea.selectionText

Sun Apr 29 00:29:41 PDT 2012

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