[whatwg] Request for new DOM property textarea.selectionText

On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Apr 29, 2012, at 1:41 PM, David Young <dyoung at pobox.com> wrote:
>
> > On Sun, Apr 29, 2012 at 10:38:26AM +0300, Aryeh Gregor wrote:
> >> On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa <rniwa at webkit.org>
> wrote:
> >>> 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.
> >>
> >> Ranges don't exist in plaintext areas.  How would you get a Range
> >> object that selects text in a textarea?  That's why we have separate
> >> .selectionStart, .selectionEnd, etc. properties to start with.
> >
> > When you say that ranges do not exist in plaintext areas (not quite sure
> > what plaintext means in this context), is that for some reason, or is it
> > just a historical artifact?
>
> 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.

Ojan

Received on Monday, 30 April 2012 14:51:47 UTC