[whatwg] Request for new DOM property textarea.selectionText

[Ian Hickson]

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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'