Oh right, of course. Thank-you.
On Tue, Jun 17, 2014 at 5:00 PM, Ben Peters <ben.pet...@microsoft.com> wrote: > On Tue, Jun 17, 2014 at 4:50 PM, Olivier F <teleclim...@gmail.com> wrote: > > On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent <jpar...@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. > >
