- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Wed, 18 Jun 2014 00:00:57 +0000
- To: Olivier F <teleclimber@gmail.com>, Julie Parent <jparent@google.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 17, 2014 at 4:50 PM, Olivier F <teleclimber@gmail.com> wrote: > On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent <jparent@google.com> wrote: >> An app can have a cursor that isn't a native browser cursor. For example, >> Google Docs does not use native browser cursors and draws their own, so that >> they can show multiple cursors for collaborators and control selections >> entirely the way they want. > > OK, I can see that. > > Would commandEvents=true fire cursor movement intents? Or is that strictly a > byproduct of setting cursor=true? I can imagine pages that use > commandEvents=true would want those events too. > > Maybe setting cursor=true only draws the cursor when the Element is focused > and moves it around according to default behavior without firing events. But > if the page wants to control that behavior they set commandEvents=true and > cursor=true to intercept and prevent default cursor movements? > A cursor is just a type of selection. It happens to not show up in non-editable content, but if it's there, it will fire Selection events just like any other selection. So commandEvents=true is not needed here.
Received on Wednesday, 18 June 2014 00:02:22 UTC