Re: [editing] Leading with ContentEditable=Minimal

On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Jun 17, 2014, at 1:44 PM, Julie Parent <jparent@google.com> wrote:
>
>
> On Tue, Jun 17, 2014 at 12:22 PM, Olivier F <teleclimber@gmail.com> wrote:
>
>> On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent <jparent@google.com> wrote:
>>
>>>
>>> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters <Ben.Peters@microsoft.com>
>>> wrote:
>>>
>>>> On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent <jparent@google.com>
>>>> wrote:
>>>> > If Intention events are (temporarily) moved out of scope,
>>>>
>>>> I don’t think I’d say they’re out of scope, just that they will likely
>>>> not be ready as quickly as we could do contentEditable=’minimal’. Do you
>>>> agree with that?
>>>>
>>>
>>> Agreed in general, but it would depend on how contentEditable='min' is
>>> actually defined.
>>>
>>> > I think this leads us back to the question of what would
>>>> contentEditable='minimal' do exactly?  Enable collapsed selections and
>>>> default handling of cursor movement ... anything else?
>>>>
>>>> Yes we need to define this default functionality. What does everyone
>>>> think about this?
>>>>
>>>> > If this is all it would do, then perhaps what we really want is an
>>>> explicit API to enable cursors?
>>>>
>>>> I think we should still think of this as a path to a full story that
>>>> includes Intention events. Are you saying that ultimately we would have
>>>> something like this?
>>>>
>>>> <div cursor=”true” commandEvents=”true”>minimally editable content</div>
>>>>
>>>> Like all other content, this would also get drag/drop, clipboard, and
>>>> selection events. We would need 3 specs for this- Selection API, minimal
>>>> editing (cursor-only editing?), and CommandEvent.
>>>>
>>>
>>> Yes. I really like the idea of explicitly enabling what you want and of
>>> separating the concepts.  Being able to turn on commandEvents independent
>>> of a cursor seems useful.  An API like this leaves far fewer questions of
>>> "what does it do?" than contentEditable="minimal".  What does cursor="true"
>>> do? It turns on the ability for the user or developer to place a cursor,
>>> and default movement.  It has nothing to do with dom modification.  What
>>> does commandEvents="true" do? It enables dispatching commandEvents.  No
>>> ambiguity.  However, this does make me think again about using
>>> beforeinput/input events rather than adding new CommandEvents, since those
>>> would include drag/drop and clipboard as well?
>>>
>>>
>> I really like cursor=true.
>>
>> I'm more confused about commandEvents=true as a separate attribute.
>>
>> - Do CommandEvents make any sense without a cursor? In particular, how
>> does end-user focus an area that has commandEvents=true if there is no
>> cursor?
>>
>
> 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.  They have to use a hidden focused
> contentEditable region in order to get all the events they need now, but it
> would be a much nicer solution for them to simply enable the events.
>
>
> How does that work in mobile?  iOS for example shows lollipops at the end
> of selections to trigger editing actions such as copy, paste, etc... if a
> web content was drawing its own cursor, then these UIs can't be shown for
> the user.  It seems to me that what they want is to use the native cursor
> and do every editing operation themselves.
>

The sad answer, at least for the Docs case I was referring to, is that they
aren't using web content on mobile, they are writing native apps.  Your
point is still valid, but I think the selection API would need to be
significantly extended in order for them to make use of it, rather than
doing their own thing.  In particular, they want to be able to draw
multiple cursors (the primary user selection and those of collaborators)
and to control the granularity of selection movement throughout different
types of rich content, in a better way than you get by just using
ce='false' regions inside an editable regions.  It would be great to evolve
to selection API to encompass these use cases as well, but I think that is
outside the scope of this discussion.


> I'm also not certain how we're going to expose an element with cursor=true
> but commandEvent=false or cursor=false but commandEvent=true to an
> assistive technology.
>
> - R. Niwa
>