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
On Mon, 30 Apr 2012, Ojan Vafai wrote:
On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@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
On Mon, Apr 30, 2012 at 11:01 PM, Ian Hickson i...@hixie.ch 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
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
On Mon, Apr 30, 2012 at 11:01 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 30 Apr 2012, Ojan Vafai wrote:
On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com
wrote:
Aryeh is referring to the DOM Range interface, which can only apply to
nodes that are directly in the
thanks all for discussing this...
As an application developer I just want a consistent way across
browser to do this operation..
On Sun, Apr 29, 2012 at 12:38 AM, Aryeh Gregor a...@aryeh.name 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
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 atextarea, 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
On 4/30/12 10:11 AM, David Young wrote:
I guess thattextarea 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
On Mon, Apr 30, 2012 at 08:55:04AM +0300, Aryeh Gregor wrote:
On Sun, Apr 29, 2012 at 11:39 PM, David Young dyo...@pobox.com wrote:
I'm curious what advantages document.execCommand() has over the
customary DOM API for adding/deleting/moving nodes?
execCommand() does vastly more complicated
On Mon, Apr 30, 2012 at 7:35 AM, David Young dyo...@pobox.com 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 dyo...@pobox.com wrote:
I'm curious what advantages document.execCommand() has over the
customary DOM API for
On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 1:41 PM, David Young dyo...@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 rn...@webkit.org
wrote:
That sounds like
On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson i...@hixie.ch 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
On Mon, Apr 30, 2012 at 5:35 PM, David Young dyo...@pobox.com 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.
On Mon, Apr 30, 2012 at 10:41 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai o...@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
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
On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@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
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()
On Sun, Apr 29, 2012 at 10:38:26AM +0300, Aryeh Gregor wrote:
On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@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
On Apr 29, 2012, at 1:41 PM, David Young dyo...@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 rn...@webkit.org wrote:
That sounds like a tangential issue. We can easily extend execCommand to
support arbitrary
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
On 4/29/12 11:24 PM, David Young wrote:
It seems that the text contents of atextarea, 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
On Sun, Apr 29, 2012 at 11:39 PM, David Young dyo...@pobox.com 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:
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
On Sat, Apr 28, 2012 at 9:30 AM, Ian Hickson i...@hixie.ch 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
On Sat, 28 Apr 2012, Ryosuke Niwa wrote:
On Sat, Apr 28, 2012 at 9:30 AM, Ian Hickson i...@hixie.ch 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
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 =
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 i...@hixie.ch wrote:
On Mon, 10 May 2010, Biju wrote:
Can we have a new DOM property textarea.selectionText which
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
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
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
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
Can we have a new DOM property textarea.selectionText
I definitely support this proposal.
Me too, if that counts. =)
--
Shashi - identi.ca/shashi
33 matches
Mail list logo
