Request for new DOM property textarea.selectionText

[David Young]

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@...> 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?

Dave

--
David Young
dyoung@...    Urbana, IL    [phone]

[Maciej Stachowiak]

On Apr 29, 2012, at 1:41 PM, David Young <dyoung@...> 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@...> 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.

Regards,
Maciej

[David Young]

On Sun, Apr 29, 2012 at 02:10:14PM -0700, Maciej Stachowiak 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.

Ok, I am a little bit familiar with the DOM Range interface.

It seems that the text contents of a <textarea>, at least, could be
properly in the DOM?  I see that an <input> uses a value attribute
instead of a subordinate text node, so I suppose DOM Range may be less
sensible and/or more difficult to apply there.

If Ryosuke wants to use one API to address ranges of text be they part
of a text control or not, then that makes sense to me.

Dave

--
David Young
dyoung@...    Urbana, IL    [phone]

[Boris Zbarsky]

On 4/29/12 11:24 PM, David Young wrote:
> It seems that the text contents of a<textarea>, at least, could be
> properly in the DOM?

Not really: when you type in a textarea, that doesn't change its actual
DOM kids.  Both per spec, and in UAs, and web content depends on this.

-Boris

[Aryeh Gregor-4]

On Sun, Apr 29, 2012 at 11:39 PM, David Young <dyoung@...> wrote:
> I'm curious what advantages document.execCommand() has over the
> customary DOM API for adding/deleting/moving nodes?

execCommand() does vastly more complicated things than the DOM APIs.
See the spec for details:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

thanks all for discussing this...
As an application developer I just want a consistent way across
browser to do this operation..

[Ryosuke Niwa-2]

On Sun, Apr 29, 2012 at 12:38 AM, Aryeh Gregor <ayg@...> wrote:

>
>  > In this case, we have an API, namely document.execCommand, supported by
> two
> > major browser engines (for years) that provides more or less the same
> > functionality as the proposed API.
>
> delete works in IE as well as WebKit.  insertText (which is what would
> be needed for this feature) is WebKit-only, in both plaintext and
> richtext.
>

That's unfortunate. FWIW, your editing spec defines InsertText:
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-inserttext-command
so we could make it work with input/textarea elements.

On one hand, being able to replace a part of text inside input/textarea
will be a useful feature. On the other hand, I don't think it'll be
efficient per se because the easiest implementation of this API is to
serialize the value, string-replace, and then put it back to
input/textarea. Making it work efficiently requires a bit of work (at least
in WebKit).

- Ryosuke

[David Young]

On Sun, Apr 29, 2012 at 11:30:20PM -0400, Boris Zbarsky wrote:
> On 4/29/12 11:24 PM, David Young wrote:
> >It seems that the text contents of a<textarea>, at least, could be
> >properly in the DOM?
>
> Not really: when you type in a textarea, that doesn't change its
> actual DOM kids.  Both per spec, and in UAs, and web content depends
> on this.

I guess that <textarea> has worked this way for a very long time,
so changing it may not be possible.  I'm curious to see examples of
which/how web content depends on it?

Dave

--
David Young
dyoung@...    Urbana, IL    [phone]

[Boris Zbarsky]

On 4/30/12 10:11 AM, David Young wrote:
> I guess that<textarea>  has worked this way for a very long time,
> so changing it may not be possible.  I'm curious to see examples of
> which/how web content depends on it?

I don't have links offhand, but I've definitely seen scripts assuming
that getting the text kids of a textarea will give the default value.

-Boris

[David Young]

On Mon, Apr 30, 2012 at 08:55:04AM +0300, Aryeh Gregor wrote:
> On Sun, Apr 29, 2012 at 11:39 PM, David Young <dyoung@...> wrote:
> > I'm curious what advantages document.execCommand() has over the
> > customary DOM API for adding/deleting/moving nodes?
>
> execCommand() does vastly more complicated things than the DOM APIs.
> See the spec for details:
>
> http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

I have seen this spec before.  It seems to have something to do
with creating a word processor-like environment in the browser,
something that I am acutely interested in, but there isn't much
introduction/justification to it.  Is there an executive summary of the
editing API somewhere?

Dave

--
David Young
dyoung@...    Urbana, IL    [phone]

[Tab Atkins Jr.]

On Mon, Apr 30, 2012 at 7:35 AM, David Young <dyoung@...> wrote:

> On Mon, Apr 30, 2012 at 08:55:04AM +0300, Aryeh Gregor wrote:
>> On Sun, Apr 29, 2012 at 11:39 PM, David Young <dyoung@...> wrote:
>> > I'm curious what advantages document.execCommand() has over the
>> > customary DOM API for adding/deleting/moving nodes?
>>
>> execCommand() does vastly more complicated things than the DOM APIs.
>> See the spec for details:
>>
>> http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
>
> I have seen this spec before.  It seems to have something to do
> with creating a word processor-like environment in the browser,
> something that I am acutely interested in, but there isn't much
> introduction/justification to it.  Is there an executive summary of the
> editing API somewhere?

Note: that spec isn't *creating* anything like that, it's just
documenting the *existing* execCommand() API that all browsers
implement, but inconsistently and incompatibly.

~TJ

[Ojan Vafai-2]

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

>
> On Apr 29, 2012, at 1:41 PM, David Young <dyoung@...> 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@...>
> 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

[Ojan Vafai-2]

On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson <ian@...> 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

[Aryeh Gregor-4]

On Mon, Apr 30, 2012 at 5:35 PM, David Young <dyoung@...> wrote:
> I have seen this spec before.  It seems to have something to do
> with creating a word processor-like environment in the browser,
> something that I am acutely interested in, but there isn't much
> introduction/justification to it.  Is there an executive summary of the
> editing API somewhere?

I filed a bug to remind me to add a better intro at some point, but no
guarantees that I'll get to it in the foreseeable future:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16894

You can read tutorials and such that you can find by Googling
"contenteditable" or "execCommand".  This page looks especially good,
at a glance, like most things written by Mark Pilgrim:

http://blog.whatwg.org/the-road-to-html-5-contenteditable

On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai <ojan@...> wrote:
> 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.

.setText("foo") sounds like it should set the entire text, not just
the selected text.

[Ryosuke Niwa-2]

On Mon, Apr 30, 2012 at 10:41 PM, Aryeh Gregor <ayg@...> wrote:
>
>  On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai <ojan@...> wrote:
> > 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.
>
> .setText("foo") sounds like it should set the entire text, not just
> the selected text.
>

I think the problem is that it automatically uses selectionStart &
selectionEnd when offsets are not supplied.
The semantics would have been much clearer if offsets were not optional.

I'd argue that we should either disallow setText without offsets, or
setText should use 0 and the length of the text field instead of
selectionStart and selectionEnd respectively when offsets are omitted.

- Ryosuke

[Ian Hickson]

On Mon, 30 Apr 2012, Ojan Vafai wrote:

> On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak <mjs@...> 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.   `._.-(,_..'--(,_..'`-.;.'

[Ryosuke Niwa-2]

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

> On Mon, 30 Apr 2012, Ojan Vafai wrote:
> > 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.)
>

In theory, this is possible. But any sort of proxy, etc... that lazily
obtain the value (e.g. delaying it until substr, etc... is called) is hard
to implement in practice because we need to serialize text before DOM is
modified. e.g.

1 var inputValue = input.value;
2 var textUsed = input.value.substr(5, 10);

In the above example, inputValue could be a proxy object. However, in the
example below:

1 var inputValue = input.value;
2 input.value = 'bar';
3 var textUsed = input.value.substr(5, 10);

we need to serialize the string immediately before the statement in the
line 2 is evaluated.

- Ryosuke

[Ian Hickson]

On Mon, 30 Apr 2012, Ryosuke Niwa wrote:

> >
> > 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.)
>
> In theory, this is possible. But any sort of proxy, etc... that lazily
> obtain the value (e.g. delaying it until substr, etc... is called) is
> hard to implement in practice because we need to serialize text before
> DOM is modified. e.g.
>
> 1 var inputValue = input.value;
> 2 var textUsed = input.value.substr(5, 10);
>
> In the above example, inputValue could be a proxy object. However, in
> the example below:
>
> 1 var inputValue = input.value;
> 2 input.value = 'bar';
> 3 var textUsed = input.value.substr(5, 10);
>
> we need to serialize the string immediately before the statement in the
> line 2 is evaluated.

That's just copy-on-write. It's hardly rocket science. :-P

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

[Ojan Vafai-2]

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

> On Mon, 30 Apr 2012, Ojan Vafai wrote:
> > On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak <mjs@...>
> 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.

[Ian Hickson]

Context:

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

On Sat, 28 Apr 2012, Maciej Stachowiak wrote:

> > [regarding using execCommand() instead]
>
> Does this work in any non-WebKit browsers? (Asking mainly out of
> curiosity; I would tend to agree in any case that adding nontrivial
> editing APIs that are specific to only plaintext editable controls is
> not a good idea. But it might be nice to specify explicitly whether
> execCommand works on form controls.)
>
> While I would not go out of my way to praise execCommand, setRangeText
> is also not a very good API design:
>
> 1) setRangeText is a vague and confusing name. If its only function was
> replacing the selection, then replaceSelection would be much better,
> but:
>
> 2) The method is overloaded to do a variety of tangentially related
> things. The overloading makes it hard to give it a good name. If the
> different operations were different methods, it would be easier to name
> it well (replaceSelection, replaceRange), but it's hard to describe all
> four of the selection modes.
>
> 3) It's not clear that all of the different selection modes of this
> function have use cases.

The method was directly based on the use cases presented by authors
earlier in this thread. It's basically two things: changing the selected
text, and changing a specific (not necessarily selected) part of the text,
without changing the selection.

We could indeed have

   setSelectionText(newText)
   setRangeText(newText, start, end, action)

...but I'm not sure that's really better.


On Sun, 29 Apr 2012, Aryeh Gregor wrote:
> >
> > 3) It's not clear that all of the different selection modes of this
> > function have use cases.
>
> In particular, the fourth argument's effect seems trivial to replicate
> using .selectionStart and .selectionEnd, so why is it worth the extra
> API surface area?

It's trivial in that it's not complicated, but it's nonetheless a pain in
the neck. That's what the original complaint was about.


On Sun, 29 Apr 2012, Ryosuke Niwa wrote:
>
> In this case, we have an API, namely document.execCommand, supported by
> two major browser engines (for years) that provides more or less the
> same functionality as the proposed API.

I really don't think it makes sense to use execCommand() with text fields.
It's the contenteditable API. I think we should move towards having it
just work for contenteditable, not move towards having it work in text
fields as well.


On Mon, 30 Apr 2012, Ryosuke Niwa wrote:

> On Mon, Apr 30, 2012 at 10:41 PM, Aryeh Gregor <ayg@...> wrote:
> > On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai <ojan@...> wrote:
> > > 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.
> >
> > .setText("foo") sounds like it should set the entire text, not just
> > the selected text.
>
> I think the problem is that it automatically uses selectionStart &
> selectionEnd when offsets are not supplied. The semantics would have
> been much clearer if offsets were not optional.
>
> I'd argue that we should either disallow setText without offsets, or
> setText should use 0 and the length of the text field instead of
> selectionStart and selectionEnd respectively when offsets are omitted.

Replacing the selected text was one of the main use cases leading to this.

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