[whatwg] Request for new DOM property textarea.selectionText
Ojan Vafai
ojan at chromium.org
Mon Apr 30 15:03:23 PDT 2012
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
More information about the whatwg
mailing list