On Jun 17, 2014, at 1:44 PM, Julie Parent <jpar...@google.com> wrote:
> > On Tue, Jun 17, 2014 at 12:22 PM, Olivier F <teleclim...@gmail.com> wrote: > On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent <jpar...@google.com> wrote: > > On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters <ben.pet...@microsoft.com> wrote: > On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent <jpar...@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. 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
