- From: Julie Parent <jparent@google.com>
- Date: Mon, 16 Jun 2014 17:48:48 -0700
- To: Ben Peters <Ben.Peters@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CAPSmAATZweKDn281Ptj8d77u8iARe2rOW3Rpd0GUT2AMTrtwLA@mail.gmail.com>
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?
Received on Tuesday, 17 June 2014 00:49:16 UTC