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

RE: [editing] Leading with ContentEditable=Minimal

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>
Message-ID: <31ae1f47189646bbb8a34e0fb3cafaa0@BLUPR03MB437.namprd03.prod.outlook.com>
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

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