Re: [editing] Leading with ContentEditable=Minimal

> On Jun 22, 2014, at 9:19 PM, Julie Parent <jparent@google.com> wrote:
> 
> 
>> 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�ft think I�fd say they�fre out of scope, just that they will likely not be ready as quickly as we could do contentEditable=�fminimal�f. 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=�htrue�h commandEvents=�htrue�h>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)

I don't think cursors for collaborators need to be drawn by the UA since users won't be interacting with those directly.

> 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.

Could you elaborate on what kind of granularity they need?

> 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.

While we may not immediately satisfy all of their needs, we should still take their use cases into our consideration so that new API will be forward compatible with their use cases if any.

- R. Niwa