Re: [editing] Leading with ContentEditable=Minimal

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

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.