Request for new DOM property textarea.selectionText

Can we have a new DOM property textarea.selectionText
which can be used to set/get selection text of a TEXTAREA/INPUT type=text.

Current method is complicated and varies between IE and Firefox


Thanks
BijuGC

PS,
I have already submitted https://bugzilla.mozilla.org/show_bug.cgi?id=404981
Trying to programmatically replace a small selection text in TEXTAREA
with a large text content is slow in Firefox due to
https://bugzilla.mozilla.org/show_bug.cgi?id=190147
But I know if we paste manually it works fast enough. So may be having
.selectionText helps

[Anne van Kesteren-2]

On Mon, 10 May 2010 07:11:06 +0200, Biju <bijumaillist@...> wrote:
> Can we have a new DOM property textarea.selectionText
> which can be used to set/get selection text of a TEXTAREA/INPUT  
> type=text.
>
> Current method is complicated and varies between IE and Firefox

How is it complicated? Also, bugs in a feature is not a good reason to add  
more features. It only increases the amount of bugs and complicates the  
overall platform.

> Thanks
> BijuGC
>
> PS,
> I have already submitted  
> https://bugzilla.mozilla.org/show_bug.cgi?id=404981
> Trying to programmatically replace a small selection text in TEXTAREA
> with a large text content is slow in Firefox due to
> https://bugzilla.mozilla.org/show_bug.cgi?id=190147
> But I know if we paste manually it works fast enough. So may be having
> .selectionText helps

--
Anne van Kesteren
http://annevankesteren.nl/

Current way in firefox is to

1. OrigStart = textarea.selectionStart
2.  textarea.value = textarea.value.substr(0, OrigStart)
                          + new_text_to_replace
                          + textarea.value.substr(textarea.selectionEnd);
3. Now u loose original selection, so

4.  textarea.setSelectionRange(OrigStart,  OrigStart+new_text_to_replace.length)
5.  remember .scrollTop and reapply if needed

Now if we are only changing few selected characters in TEXTAREA with
big text content,
we are unnecessarily replacing entire content, which is inefficient.


On IE even though wierd you can do it simply by
   document.selection.createRange().text = new_text_to_replace;
BTW, you need to make sure the selection is currently on the
textarea/input form control.
IE is also very fast when doing that, when firefox hangs few second
using the other way

[Ojan Vafai-2]

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.

Ojan

On Mon, May 10, 2010 at 12:59 AM, Biju <bijumaillist@...> wrote:

Current way in firefox is to

1. OrigStart = textarea.selectionStart
2.  textarea.value = textarea.value.substr(0, OrigStart)
                         + new_text_to_replace
                         + textarea.value.substr(textarea.selectionEnd);
3. Now u loose original selection, so

4.  textarea.setSelectionRange(OrigStart,  OrigStart+new_text_to_replace.length)
5.  remember .scrollTop and reapply if needed

Now if we are only changing few selected characters in TEXTAREA with
big text content,
we are unnecessarily replacing entire content, which is inefficient.


On IE even though wierd you can do it simply by
  document.selection.createRange().text = new_text_to_replace;
BTW, you need to make sure the selection is currently on the
textarea/input form control.
IE is also very fast when doing that, when firefox hangs few second
using the other way

[Daniel Glazman]

Le 10/05/10 07:11, Biju a écrit :

> Can we have a new DOM property textarea.selectionText
> which can be used to set/get selection text of a TEXTAREA/INPUT type=text.
>
> Current method is complicated and varies between IE and Firefox

Oh!!! As a read/write property, right?

With my editor implementor's hat on, that's a _very_ neat idea I must
say... I really like it. Probably one or two edge cases to document but
I definitely support this proposal.

</Daniel>

[ShashiGowda]

>> Can we have a new DOM property textarea.selectionText
> I definitely support this proposal.

Me too, if that counts. =)

--
Shashi - identi.ca/shashi

On Mon, May 10, 2010 at 11:50 AM, Daniel Glazman
<daniel.glazman@...> wrote:
> Le 10/05/10 07:11, Biju a écrit :
>
>> Can we have a new DOM property textarea.selectionText
>> which can be used to set/get selection text of a TEXTAREA/INPUT type=text.
>>
>> Current method is complicated and varies between IE and Firefox
>
> Oh!!! As a read/write property, right?

Yes,
But Ojan suggested another option, I liked that too.

Both have advantages

Option 1 (textobj.selectionText) advantages
* No need for web developer to provide selection start/end
* Automatically select the newly inserted text,
   (as most time that is what you want)
* No need for web developer to calculate selection start/end for
setting it after text insert
* preserve scroll
* Has both Getter and Setter

Option 2 (textobj.setRangeText(start, end, text)); advantages
* Independent of selection, web developer can change text at any range
   with out affecting selection
* Web developer has more options with it.
* preserve scroll


So I want to merge both suggestion, with a new signature,
also trying to reduce coding for web developer "less code less bug"

textobj.setRangeText(newtext, start, end, cursorpos)

parameters:
newtext
 - optional parameter
 - new text that will replace existing
 - if missing/null/undefined/NaN then default to ""

start
 - optional parameter
 - starting position of the original textobj text that need to be replaced
 - if missing/null/undefined/NaN then default to textobj.selectionStart
 - negative value make start position from last character in the text content

end
 - optional parameter
 - ending position of the original textobj text that need to be replaced
 - if missing/null/undefined/NaN then default to textobj.selectionEnd
 - negative value make end position from last character

cursorpos
 - optional parameter
 - if missing/null/undefined/NaN then default to 0
 - what should happen to cursor/selection after text insert, its values are
 - - 0 - select the newly inserted text
 - - 1 - place cursor at beginning of inserted text
 - - 2 - place cursor at the end of inserted text
 - - 3 - keep selection unaffected
* issue, when value is 3 what should we do when setRangeText is replacing text
which has some parts selected and some other parts unselected


so if somebody want replace selection text it is just
     textobj.setRangeText(newtext);
which is almost same as my original proposal, and
     textobj.setRangeText();
will blank a selection

We could also add a getter method, also with optional parameters
     textobj.getRangeText(start, end)
so,
textobj.getRangeText() gives current selection
textobj.getRangeText(0) gives from start of text to current selection end
textobj.getRangeText(null, -1) gives from current selection start to end of text

[Ian Hickson]

On Mon, 10 May 2010, Biju wrote:
>
> Can we have a new DOM property textarea.selectionText which can be used
> to set/get selection text of a TEXTAREA/INPUT type=text.

Gettng the value is relatively easy:

On Mon, 10 May 2010, Biju wrote:
>
> Current way in firefox is to
>
> 1. OrigStart = textarea.selectionStart

But admittedly setting it is a pain:

> 2.  textarea.value = textarea.value.substr(0, OrigStart)
>                           + new_text_to_replace
>                           + textarea.value.substr(textarea.selectionEnd);
> 3. Now u loose original selection, so
>
> 4.  textarea.setSelectionRange(OrigStart,  OrigStart+new_text_to_replace.length)
> 5.  remember .scrollTop and reapply if needed

I agree that making this easier would be good.


> On IE even though wierd you can do it simply by
>    document.selection.createRange().text = new_text_to_replace;
> BTW, you need to make sure the selection is currently on the
> textarea/input form control.
> IE is also very fast when doing that, when firefox hangs few second
> using the other way

IE's version is non-standard and not adopted by other UAs.


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.

On Tue, 11 May 2010, Biju wrote:

>
> Both have advantages
>
> Option 1 (textobj.selectionText) advantages
> * No need for web developer to provide selection start/end
> * Automatically select the newly inserted text,
>    (as most time that is what you want)
> * No need for web developer to calculate selection start/end for
> setting it after text insert
> * preserve scroll
> * Has both Getter and Setter
>
> Option 2 (textobj.setRangeText(start, end, text)); advantages
> * Independent of selection, web developer can change text at any range
>    with out affecting selection
> * Web developer has more options with it.
> * preserve scroll
>
> So I want to merge both suggestion, with a new signature,
> also trying to reduce coding for web developer "less code less bug"
>
> textobj.setRangeText(newtext, start, end, cursorpos)
>
> parameters:
> newtext
>  - optional parameter
>  - new text that will replace existing
>  - if missing/null/undefined/NaN then default to ""
>
> start
>  - optional parameter
>  - starting position of the original textobj text that need to be replaced
>  - if missing/null/undefined/NaN then default to textobj.selectionStart
>  - negative value make start position from last character in the text content
>
> end
>  - optional parameter
>  - ending position of the original textobj text that need to be replaced
>  - if missing/null/undefined/NaN then default to textobj.selectionEnd
>  - negative value make end position from last character
>
> cursorpos
>  - optional parameter
>  - if missing/null/undefined/NaN then default to 0
>  - what should happen to cursor/selection after text insert, its values are
>  - - 0 - select the newly inserted text
>  - - 1 - place cursor at beginning of inserted text
>  - - 2 - place cursor at the end of inserted text
>  - - 3 - keep selection unaffected
> * issue, when value is 3 what should we do when setRangeText is replacing text
> which has some parts selected and some other parts unselected
>
>
> so if somebody want replace selection text it is just
>      textobj.setRangeText(newtext);
> which is almost same as my original proposal, and
>      textobj.setRangeText();
> will blank a selection

That seems a bit overly complicated, but something in that vein seems
reasonable.

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


> We could also add a getter method, also with optional parameters
>      textobj.getRangeText(start, end)
> so,
> textobj.getRangeText() gives current selection
> textobj.getRangeText(0) gives from start of text to current selection end
> textobj.getRangeText(null, -1) gives from current selection start to end of text

Getting the text from a range is already rather simple (as demonstrated at
the top of this e-mail), so I don't think that's necessary.

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

[Ryosuke Niwa-2]

Why are we adding this new API? WebKit already supports

document.execCommand('InsertText', false, "new selected text");

- Ryosuke

On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson <ian@...> wrote:

> On Mon, 10 May 2010, Biju wrote:
> >
> > Can we have a new DOM property textarea.selectionText which can be used
> > to set/get selection text of a TEXTAREA/INPUT type=text.
>
> Gettng the value is relatively easy:
>
> On Mon, 10 May 2010, Biju wrote:
> >
> > Current way in firefox is to
> >
> > 1. OrigStart = textarea.selectionStart
>
> But admittedly setting it is a pain:
>
> > 2.  textarea.value = textarea.value.substr(0, OrigStart)
> >                           + new_text_to_replace
> >                           + textarea.value.substr(textarea.selectionEnd);
> > 3. Now u loose original selection, so
> >
> > 4.  textarea.setSelectionRange(OrigStart,
>  OrigStart+new_text_to_replace.length)
> > 5.  remember .scrollTop and reapply if needed
>
> I agree that making this easier would be good.
>
>
> > On IE even though wierd you can do it simply by
> >    document.selection.createRange().text = new_text_to_replace;
> > BTW, you need to make sure the selection is currently on the
> > textarea/input form control.
> > IE is also very fast when doing that, when firefox hangs few second
> > using the other way
>
> IE's version is non-standard and not adopted by other UAs.
>
>
> 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.
>
> On Tue, 11 May 2010, Biju wrote:
> >
> > Both have advantages
> >
> > Option 1 (textobj.selectionText) advantages
> > * No need for web developer to provide selection start/end
> > * Automatically select the newly inserted text,
> >    (as most time that is what you want)
> > * No need for web developer to calculate selection start/end for
> > setting it after text insert
> > * preserve scroll
> > * Has both Getter and Setter
> >
> > Option 2 (textobj.setRangeText(start, end, text)); advantages
> > * Independent of selection, web developer can change text at any range
> >    with out affecting selection
> > * Web developer has more options with it.
> > * preserve scroll
> >
> > So I want to merge both suggestion, with a new signature,
> > also trying to reduce coding for web developer "less code less bug"
> >
> > textobj.setRangeText(newtext, start, end, cursorpos)
> >
> > parameters:
> > newtext
> >  - optional parameter
> >  - new text that will replace existing
> >  - if missing/null/undefined/NaN then default to ""
> >
> > start
> >  - optional parameter
> >  - starting position of the original textobj text that need to be
> replaced
> >  - if missing/null/undefined/NaN then default to textobj.selectionStart
> >  - negative value make start position from last character in the text
> content
> >
> > end
> >  - optional parameter
> >  - ending position of the original textobj text that need to be replaced
> >  - if missing/null/undefined/NaN then default to textobj.selectionEnd
> >  - negative value make end position from last character
> >
> > cursorpos
> >  - optional parameter
> >  - if missing/null/undefined/NaN then default to 0
> >  - what should happen to cursor/selection after text insert, its values
> are
> >  - - 0 - select the newly inserted text
> >  - - 1 - place cursor at beginning of inserted text
> >  - - 2 - place cursor at the end of inserted text
> >  - - 3 - keep selection unaffected
> > * issue, when value is 3 what should we do when setRangeText is
> replacing text
> > which has some parts selected and some other parts unselected
> >
> >
> > so if somebody want replace selection text it is just
> >      textobj.setRangeText(newtext);
> > which is almost same as my original proposal, and
> >      textobj.setRangeText();
> > will blank a selection
>
> That seems a bit overly complicated, but something in that vein seems
> reasonable.
>
> 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
>
>
> > We could also add a getter method, also with optional parameters
> >      textobj.getRangeText(start, end)
> > so,
> > textobj.getRangeText() gives current selection
> > textobj.getRangeText(0) gives from start of text to current selection end
> > textobj.getRangeText(null, -1) gives from current selection start to end
> of text
>
> Getting the text from a range is already rather simple (as demonstrated at
> the top of this e-mail), so I don't think that's necessary.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

[Ian Hickson]

On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
>
> Why are we adding this new API? WebKit already supports
>
> document.execCommand('InsertText', false, "new selected text");

That's for contenteditable regions, right?

The new API is for <input> and <textarea>. Also, it's not limited to
replacing the selected text, it can be any region.

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

[Ryosuke Niwa-2]

All editing commands work inside input/textarea on WebKit although some of
them have no effect (e.g. bold, italic, etc...)

I think reusing execCommand is better than adding new method for
input/textarea elements for each new feature request like this one.

- Ryosuke

On Fri, Apr 27, 2012 at 9:36 PM, Ian Hickson <ian@...> wrote:

> On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
> >
> > Why are we adding this new API? WebKit already supports
> >
> > document.execCommand('InsertText', false, "new selected text");
>
> That's for contenteditable regions, right?
>
> The new API is for <input> and <textarea>. Also, it's not limited to
> replacing the selected text, it can be any region.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

[Ian Hickson]

On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
>
> All editing commands work inside input/textarea on WebKit although some
> of them have no effect (e.g. bold, italic, etc...)

That sounds rather odd...


> I think reusing execCommand is better than adding new method for
> input/textarea elements for each new feature request like this one.

If it was a contentEditable feature I'd reluctantly agree (reluctantly
because execCommand is a terrible API), but I really don't see why
execCommand() would work on input controls.

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

[Ryosuke Niwa-2]

On Sat, Apr 28, 2012 at 9:30 AM, Ian Hickson <ian@...> wrote:
>
>  > I think reusing execCommand is better than adding new method for
> > input/textarea elements for each new feature request like this one.
>
> If it was a contentEditable feature I'd reluctantly agree (reluctantly
> because execCommand is a terrible API), but I really don't see why
> execCommand() would work on input controls.


Because they're all "editing" features. How do we know someone won't
suggest adding things like input.insertParagraph(), or
input.deleteSelectedText(), etc...

- Ryosuke

[Ian Hickson]

On Sat, 28 Apr 2012, Ryosuke Niwa wrote:

> On Sat, Apr 28, 2012 at 9:30 AM, Ian Hickson <ian@...> wrote:
> > >
> > > I think reusing execCommand is better than adding new method for
> > > input/textarea elements for each new feature request like this one.
> >
> > If it was a contentEditable feature I'd reluctantly agree (reluctantly
> > because execCommand is a terrible API), but I really don't see why
> > execCommand() would work on input controls.
>
> Because they're all "editing" features.

They're very different in most sense, why should they be the same in this
one? (They have different DOM representations, different UI, different
events, different selection APIs, most of the execCommand()s only apply to
structured editors which neither <input> nor <textarea> have, etc...)


> How do we know someone won't suggest adding things like
> input.insertParagraph()

Well they can suggest it, but since text inputs are single-line editors,
they wouldn't get very far.


> or input.deleteSelectedText(), etc...

That's one of the features setRangeText supports:

   input.setRangeText('');

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

[Maciej Stachowiak]

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.

Regards,
Maciej

On Apr 27, 2012, at 9:11 PM, Ryosuke Niwa <rniwa@...> wrote:

> Why are we adding this new API? WebKit already supports
>
> document.execCommand('InsertText', false, "new selected text");
>
> - Ryosuke
>
> On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson <ian@...> wrote:
>
>> On Mon, 10 May 2010, Biju wrote:
>>>
>>> Can we have a new DOM property textarea.selectionText which can be used
>>> to set/get selection text of a TEXTAREA/INPUT type=text.
>>
>> Gettng the value is relatively easy:
>>
>> On Mon, 10 May 2010, Biju wrote:
>>>
>>> Current way in firefox is to
>>>
>>> 1. OrigStart = textarea.selectionStart
>>
>> But admittedly setting it is a pain:
>>
>>> 2.  textarea.value = textarea.value.substr(0, OrigStart)
>>>                          + new_text_to_replace
>>>                          + textarea.value.substr(textarea.selectionEnd);
>>> 3. Now u loose original selection, so
>>>
>>> 4.  textarea.setSelectionRange(OrigStart,
>> OrigStart+new_text_to_replace.length)
>>> 5.  remember .scrollTop and reapply if needed
>>
>> I agree that making this easier would be good.
>>
>>
>>> On IE even though wierd you can do it simply by
>>>   document.selection.createRange().text = new_text_to_replace;
>>> BTW, you need to make sure the selection is currently on the
>>> textarea/input form control.
>>> IE is also very fast when doing that, when firefox hangs few second
>>> using the other way
>>
>> IE's version is non-standard and not adopted by other UAs.
>>
>>
>> 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.
>>
>> On Tue, 11 May 2010, Biju wrote:
>>>
>>> Both have advantages
>>>
>>> Option 1 (textobj.selectionText) advantages
>>> * No need for web developer to provide selection start/end
>>> * Automatically select the newly inserted text,
>>>   (as most time that is what you want)
>>> * No need for web developer to calculate selection start/end for
>>> setting it after text insert
>>> * preserve scroll
>>> * Has both Getter and Setter
>>>
>>> Option 2 (textobj.setRangeText(start, end, text)); advantages
>>> * Independent of selection, web developer can change text at any range
>>>   with out affecting selection
>>> * Web developer has more options with it.
>>> * preserve scroll
>>>
>>> So I want to merge both suggestion, with a new signature,
>>> also trying to reduce coding for web developer "less code less bug"
>>>
>>> textobj.setRangeText(newtext, start, end, cursorpos)
>>>
>>> parameters:
>>> newtext
>>> - optional parameter
>>> - new text that will replace existing
>>> - if missing/null/undefined/NaN then default to ""
>>>
>>> start
>>> - optional parameter
>>> - starting position of the original textobj text that need to be
>> replaced
>>> - if missing/null/undefined/NaN then default to textobj.selectionStart
>>> - negative value make start position from last character in the text
>> content
>>>
>>> end
>>> - optional parameter
>>> - ending position of the original textobj text that need to be replaced
>>> - if missing/null/undefined/NaN then default to textobj.selectionEnd
>>> - negative value make end position from last character
>>>
>>> cursorpos
>>> - optional parameter
>>> - if missing/null/undefined/NaN then default to 0
>>> - what should happen to cursor/selection after text insert, its values
>> are
>>> - - 0 - select the newly inserted text
>>> - - 1 - place cursor at beginning of inserted text
>>> - - 2 - place cursor at the end of inserted text
>>> - - 3 - keep selection unaffected
>>> * issue, when value is 3 what should we do when setRangeText is
>> replacing text
>>> which has some parts selected and some other parts unselected
>>>
>>>
>>> so if somebody want replace selection text it is just
>>>     textobj.setRangeText(newtext);
>>> which is almost same as my original proposal, and
>>>     textobj.setRangeText();
>>> will blank a selection
>>
>> That seems a bit overly complicated, but something in that vein seems
>> reasonable.
>>
>> 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
>>
>>
>>> We could also add a getter method, also with optional parameters
>>>     textobj.getRangeText(start, end)
>>> so,
>>> textobj.getRangeText() gives current selection
>>> textobj.getRangeText(0) gives from start of text to current selection end
>>> textobj.getRangeText(null, -1) gives from current selection start to end
>> of text
>>
>> Getting the text from a range is already rather simple (as demonstrated at
>> the top of this e-mail), so I don't think that's necessary.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>

[Aryeh Gregor-4]

On Sun, Apr 29, 2012 at 9:09 AM, Maciej Stachowiak <mjs@...> wrote:
> 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.)

Test-case:

data:text/html,<!DOCTYPE html>
<input value=abc>
<script>
var input = document.body.firstChild;
input.selectionStart = 1;
input.selectionEnd = 2;
document.execCommand("delete");
</script>

This works in IE 10 Developer Preview and Chrome 20 dev, but not
Firefox 15.0a1 or Opera Next 12.00 alpha.  I guess it would make sense
to make commands like this work for plaintext editors, but I agree
that people who just want to deal with plaintext shouldn't be forced
to suffer through the horrors of execCommand() if we can make nicer
plaintext-only APIs.  Particularly since WebKit's insertText only
works on the current selection, and it's not as easy as it should be
to save and restore the selection, so an API that can deal with
arbitrary ranges directly is valuable.

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

[Ryosuke Niwa-2]

On Sat, Apr 28, 2012 at 11:37 PM, Aryeh Gregor <ayg@...> wrote:

> On Sun, Apr 29, 2012 at 9:09 AM, Maciej Stachowiak <mjs@...> wrote:
> > 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.)
>
> Test-case:
>
> data:text/html,<!DOCTYPE html>
> <input value=abc>
> <script>
> var input = document.body.firstChild;
> input.selectionStart = 1;
> input.selectionEnd = 2;
> document.execCommand("delete");
> </script>
>
> This works in IE 10 Developer Preview and Chrome 20 dev, but not
> Firefox 15.0a1 or Opera Next 12.00 alpha.

Thank you for the data points.

Particularly since WebKit's insertText only
> works on the current selection, and it's not as easy as it should be
> to save and restore the selection, so an API that can deal with
> arbitrary ranges directly is valuable.
>

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.

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

Right. In general, I'm against adding new APIs unless there is a compelling
reason to do so.

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.

- Ryosuke

[Ryosuke Niwa-2]

FYI, those commands listed below with enabledInEditableText (as supposed to
enabledInRichlyEditableText) are ones available in input/textarea for
WebKit:
http://trac.webkit.org/browser/trunk/Source/WebCore/editing/EditorCommand.cpp?rev=113031#L1442

On Sun, Apr 29, 2012 at 12:29 AM, Ryosuke Niwa <rniwa@...> wrote:

> On Sat, Apr 28, 2012 at 11:37 PM, Aryeh Gregor <ayg@...> wrote:
>
>> On Sun, Apr 29, 2012 at 9:09 AM, Maciej Stachowiak <mjs@...> wrote:
>> > 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.)
>>
>> Test-case:
>>
>> data:text/html,<!DOCTYPE html>
>> <input value=abc>
>> <script>
>> var input = document.body.firstChild;
>> input.selectionStart = 1;
>> input.selectionEnd = 2;
>> document.execCommand("delete");
>> </script>
>>
>> This works in IE 10 Developer Preview and Chrome 20 dev, but not
>> Firefox 15.0a1 or Opera Next 12.00 alpha.
>
>
> Thank you for the data points.
>
> Particularly since WebKit's insertText only
>> works on the current selection, and it's not as easy as it should be
>> to save and restore the selection, so an API that can deal with
>> arbitrary ranges directly is valuable.
>>
>
> 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.
>
> > 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?
>>
>
> Right. In general, I'm against adding new APIs unless there is a
> compelling reason to do so.
>
> 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.
>
> - Ryosuke
>
>

[Aryeh Gregor-4]

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.

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

[David Young]

On Sun, Apr 29, 2012 at 12:29:41AM -0700, 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'm curious what advantages document.execCommand() has over the
customary DOM API for adding/deleting/moving nodes?

Dave

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