[whatwg] Request for new DOM property textarea.selectionText

[Ojan Vafai]

On Mon, Apr 30, 2012 at 11:01 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 30 Apr 2012, Ojan Vafai wrote:
> > On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
> > >
> > > Aryeh is referring to the DOM Range interface, which can only apply to
> > > nodes that are directly in the DOM, and offsets into their text. The
> > > text contents of an <input> or <textarea> are not properly in the DOM,
> > > so you cannot use a DOM Range to reference such ranges. I am no sure
> > > this is what Ryosuke had in mind though; I think he just meant that in
> > > general we could support some notion of a range, and presumably we
> > > could come up with one that applies to contentEditable/designMode as
> > > well as to text controls. One extreme possibility is to simply change
> > > the definition of Range to allow it to address the contents of text
> > > input controls.
> >
> > I can't think of any approach to this that doesn't make Ranges much more
> > complicated to work with. The way the old IE APIs deal with this is to
> > have control ranges and text ranges. Control ranges are for form
> > controls and images. Text ranges are kind of like DOM ranges, but a
> > little less general. When you get the range from the selection, you get
> > either a control range or a text range and all your code needs to be
> > aware of which one it's got because they have slightly different APIs.
> >
> > I agree that the idea of one Range to rule them all sounds nice at a
> > high-level, but I think in practice, you'll inevitably end up with
> > something complicated like the IE ranges. The world is much simpler for
> > browser vendors and web devlopers if Range is restricted to the DOM and
> > text inputs just have special-cased APIs. Each API can focus on being
> > good for its one use-case.
>
> Yeah, that's pretty much why I haven't gone that route.
>
>
> On Mon, 30 Apr 2012, Ojan Vafai wrote:
> > >
> > > 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
> > >
> > > [...]
> >
> > 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 don't mind calling it something else, but as Aryeh points out, "text" or
> "setText" would make the common case (replacing the selection) really
> unintuitive to read. It does always affect a range, even if the range is
> implied by the lack of explicit start/end arguments.
>
>
> > 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).
>
> Is that really that expensive? Seems like it'd be better just to have UAs
> optimise their JS string implementations so that it can just be backed by
> the same thing as the DOM or the control's editor. (I believe Mozilla may
> in fact already do that.)
>

Fair enough.