Re: [editing] Leading with ContentEditable=Minimal

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.


> - If commandEvents are just events with no default action, can they not
> fire safely wherever cursor=true? If the page code does not listen for the
> event and react, nothing happens. If the page wants to do anything with a
> command event, it just needs to observe said event.
>

True, and perhaps that could simply things. Events aren't free for the
browser though, so there is a cost of having them fire needlessly.


> I'm assuming here that text insert is a commandEvent and that the page dev
> takes care of updating the DOM with inserted text (including partial edits
> with composition events). I guess that part is still up for debate :)
>
> I am further assuming "CommandEvents" refers to low level intent events
> like "deleteToBeginningOfLine" (although they could also eventually refer
> to "boldSelection").
>
> I want to clarify that in my opinion cursor=true (or commandEvents=true)
> should in no way imply that the UA should show a WYSIWIG editing UI (bold
> buttons and context menu entries, etc...). My editor may be a code editor
> where a "bold" command makes no sense whatsoever and having "bold" button
> looks silly and confusing.
>
> I can imagine we would eventually create an API that allows page devs to
> tell the UA that certain WYSIWYG controls should be shown, and control
> their state, and they should fire commandEvents. This could be a nice
> additional building block for editor devs in the future. However the
> default should be don't show any UA-native WYSIWYG or text editing controls.
>