[whatwg] Request for new DOM property textarea.selectionText

On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 10 May 2010, Ojan Vafai wrote:
> >
> > In addition to selection and scroll issues, needing to replace the
> > entire textarea value doesn't scale and thus limits what sorts of things
> > you can do with textareas. A general way to set a sub-part of a
> > textarea's value seems useful to me. I don't think we should tie that to
> > setting the selected text though.
> >
> > textarea.setRangeText(start, end, text);
> >
> > It replaces the text between start and end, maintains current scroll
> > position and preserves the selection.
> I've added
>
>   setRangeText(newText); // replace selection with newText
>   setRangeText(newText, start, end); // replace given range with newText
>   setRangeText(newText, start, end, action); // see below
>
> ...where action is one of:
>
>   'select': selects the new text
>   'start': selects empty range at start of new text
>   'end': selects empty range at end of new text
>   'preserve': (default) set selection as follows:
>
>    - if selection start was before range, leave as is
>    - if selection start was after the old range, put it as far from the
>      end of the new range as it was from the end of the old range
>    - if selection start was in the old range, move it to the start of the
>      new range
>
>    - if selection end was before range, leave as is
>    - if selection end was after the old range, put it as far from the
>      end of the new range as it was from the end of the old range
>    - if selection emd was in the old range, move it to the end of the
>      new range


This looks good to me. Could we just call the method setText though since
the range values are optional. setRangeText, in retrospect, is wordy and
confusing in a way that setText isn't IMO. We could even go fully jQuery
style and just call the method "text".

I'd also like to see us expose a method for getting the text that accepts
optional start/end arguments. Mainly, this allows for the possibility of
browser vendors to performance optimize (e.g. don't need to convert the
whole string to a JS string just to get the 5 selected characters out).

So, in addition to setText, we could have:
text(); // same value as the value property or should this be just the
selected text?
text(start, end); // get text from start to end
setText(newText); // replace selection with newText
setText(newText, start, end); // replace given range with newText
setText(newText, start, end, action); // see below

And if we wanted to go fully jQuery style, we could do:
text(); // same value as the value property or should this be just the
selected text?
text(start, end); // get text from start to end
text(newText); // replace selection with newText
text(newText, start, end); // replace given range with newText
text(newText, start, end, action); // see below

While that sort of overloading kind of hurts to look at, I think jQuery has
shown it to be a much-loved pattern on the web. I'd be happy with either
solution. In practice, it's clear from the calling location what's going on.

Ojan

Received on Monday, 30 April 2012 15:03:23 UTC