On 29 June 2012 21:46, Ian Hickson i...@hixie.ch wrote:
Given the lack of interest in the feature, I have removed it from the spec
and recommend to implementors that they drop support for the API.
What's the procedure for proposing a new API to address the same use
cases I've described earlier
On 21 July 2011 20:59, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Jul 20, 2011 at 6:23 PM, Tim Down timd...@gmail.com wrote:
Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.
It shouldn't be *too* hard
On 6 January 2011 21:53, Ian Hickson i...@hixie.ch wrote:
On Wed, 27 Oct 2010, benjamin.poul...@nokia.com wrote:
I would like to suggest a change for the main HTML 5 specification:
http://www.whatwg.org/specs/web-apps/current-work/
The problem I have is with the Window object specification
On 20 July 2011 17:58, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Jul 20, 2011 at 6:14 AM, Tim Down timd...@gmail.com wrote:
It's useful for custom search features. I've recommended it a few
times on Stack Overflow for people wanting to highlight or somehow
style all occurrences
On 31 May 2011 18:39, Aryeh Gregor simetrical+...@gmail.com wrote:
On Tue, May 31, 2011 at 4:15 AM, Markus Ernst derer...@gmx.ch wrote:
Anyway, everything we need is actually available in the DOM, except a
standardized and simple handling of selections and ranges. (Well, I might be
wrong - but
On 31 May 2011 09:15, Markus Ernst derer...@gmx.ch wrote:
While following the discussions about Aryeh Gregor's great work on
execCommand(), I get the impression that this method is very limited to some
basic formatting actions. It provides shortcuts for a limited set of DOM
actions, but is not
On 19 May 2011 21:10, Aryeh Gregor simetrical+...@gmail.com wrote:
(You know that
!DOCTYPE HTML
style
span { border: solid black 1px; }
/style
pspanOne/span/pspan
/spanpspanTwo/span/p
will behave the same as what you wrote and is just as conformant, right?)
Actually I didn't. Thanks
I have a couple of general questions about the HTML Editing Commands spec:
1) Will there be any provision for special handling of whitespace text
nodes? I notice that WebKit leaves them alone. For example, running
document.execCommand(bold, false, null) for the following HTML with
selection
On 12 May 2011 19:06, Aryeh Gregor simetrical+...@gmail.com wrote:
Really the whole idea of multiple Ranges per Selection is underdefined
right now, since AFAIK only Gecko supports it at all, and the way it
does it is weird and we don't really want to spec it, and other
engines don't seem to
On 10 May 2011 16:42, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, May 10, 2011 at 8:33 AM, Ojan Vafai o...@chromium.org wrote:
What's the difference between selectstart and selectionchange in WebKit?
In IE is this case the only difference between the two?
selectstart fires before selection
Are there any plans for selection-related events for editable HTML
content (contenteditable or designMode)? An event that fires whenever
the selection changes would be very useful and seems a curious
oversight in most current browsers. The current situation is:
- There are two events that exist:
On 7 April 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote:
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
IIRC from testing
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
Tim
On 1 March 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote:
Two or three weeks ago I began writing a specification for
execCommand() and
On 18 March 2011 00:43, Aryeh Gregor simetrical+...@gmail.com wrote:
On Thu, Mar 17, 2011 at 6:45 PM, Tim Down timd...@gmail.com wrote:
I'm interested in this stuff and am very grateful for your work. I've
been writing a document.execCommand() replacement for my Rangy library
(http
On 4 February 2011 01:25, Aryeh Gregor simetrical+...@gmail.com wrote:
On Thu, Feb 3, 2011 at 4:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
And all I'm saying is that there are at least three pieces of data here:
1) innerText return value
2) Selection.toString() return value
3) What the
On 4 February 2011 11:07, Marijn Haverbeke mari...@gmail.com wrote:
See below for a revised proposal, based on the discussion here. To
move this forward, I understand I must get some people to implement
it. I'll probably eventually get to submitting a Firefox patch. If
anyone reading this list
It seems to me like there's an additional complication: presumably
Selection.modify() acts on only the text that is visible to the user,
which lands you with the problem of first specifying what that text
is. This is similar to the problem presented by specifying the
toString() method of Selection
On 28 January 2011 16:53, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jan 28, 2011 at 7:59 AM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
2) Have WebKit or Opera run into any websites that depend on being
able to use multiple Ranges per Selection?
As far as I
On 14 January 2011 10:16, Marijn Haverbeke mari...@gmail.com wrote:
Another relevant precedent is window.getSelection().modify (Webkit and
Gecko-2 specific), which uses the strings forward and backward to
specify the direction in which to alter the selection. English is not
my native language,
On 14 January 2011 11:33, Marijn Haverbeke mari...@gmail.com wrote:
If you don't need the TextRange-like character-based modification, you
can instead use the selection's extend() method (supported in Mozilla,
WebKit and Opera for years) to create a backwards selection:
Maybe that is what you
On 13 January 2011 08:48, Marijn Haverbeke mari...@gmail.com wrote:
Rather than a single string property, how about integer
selectionAnchor and selectionFocus properties? This is then analogous
to Selection's anchorNode, anchorOffset, focusNode and focusOffset
properties and avoids an awkward
I completely agree, and have been lobbying for similar functionality
for the main document selection object, resulting in the current
ongoing discussion in this bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624.
Rather than a single string property, how about integer
selectionAnchor and
;
3. Change the specification of the toString() method of Selection
objects to match current browser behaviour.
Tim Down
23 matches
Mail list logo
