Oh right, of course. Thank-you.
On Tue, Jun 17, 2014 at 5:00 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:
> 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.
>
>