- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 2 Jun 2012 00:05:35 +0000 (UTC)
- To: whatwg <whatwg@whatwg.org>
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@aryeh.name> wrote:
> > On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai <ojan@chromium.org> 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. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 2 June 2012 00:06:04 UTC