W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [editing] Leading with ContentEditable=Minimal

From: Olivier F <teleclimber@gmail.com>
Date: Tue, 17 Jun 2014 17:52:57 -0700
Message-ID: <CAA5DY6ZvXZQH_5soHQdAixgUATZPkGfUqLV_Q-Bu_opN8O6toA@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: Julie Parent <jparent@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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.
>
>
Received on Wednesday, 18 June 2014 00:53:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC