- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 10 May 2011 08:33:50 -0700
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 >
Received on Tuesday, 10 May 2011 08:33:50 UTC