[whatwg] Selection events in editable content

Ojan Vafai ojan at chromium.org
Tue May 10 08:33:50 PDT 2011

On Mon, May 9, 2011 at 9:05 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Fri, May 6, 2011 at 8:55 AM, Tim Down <timdown at gmail.com> wrote:
> >
> > - There are two events that exist: select and selectstart
> > - In IE, the selectstart event fires whenever the user starts changing
> > the selection within any contenteditable element, including when the
> > user chooses "Select all" from the edit or context menus. It also
> > fires on the <body> element when the user starts making a selection
> > anywhere in the page.
> >
> One question about selectstart.  WebKit currently fires whenever selection
> is modified by a mouse drag, mouse click, etc... including when a collapsed
> selection is to be set (caret / insertion point).  Should this be changed
> to
> match IE?
> IE only fires selectstart when a range selection is to be created. So when
> a
> user clicks on a contenteditable area and puts a caret, it doesn't fire
> selectstart. IE fires selectstart only when a user starts dragging the
> mouse
> and extend the selection.

What's the difference between selectstart and selectionchange in WebKit? In
IE is this case the only difference between the two?

> On the one hand, it seems strange to special-case collapsed selection.  On
> the other hand, it allows IE to also fire selectstart when a user uses
> keyboard (shift+arrow keys) to modify selection. Also, if we're firing
> selectstart whenever a collapsed selection is set, then it seems like we
> should also fire selectstart when a focused node is changed, and that
> doesn't such an odd thing to do.
> If we're serious about spec'ing this event, we should investigate the order
> in which this event is fired in relation to other events since it's
> cancelable.
> - Ryosuke

More information about the whatwg mailing list