RE: Should we use BeforeInputEvent instead of CommandEvent?

Since BeforeInput is being spec’d in DOM L3 Events, I’ve added Gary to this discussion. What would the “intent” look like in the Interface? Is it an enum, object reference, or something else?

From: Ben Peters [mailto:Ben.Peters@microsoft.com]
Sent: Wednesday, July 16, 2014 12:54 PM
To: Piotr Koszuliński; Julie Parent
Cc: Ojan Vafai; public-editing-tf@w3.org
Subject: RE: Should we use BeforeInputEvent instead of CommandEvent?

I agree that that we need intention information in beforeinput if we use it.

We do need to start working on a consensus here. I think the next step is to create list of Intentions and what event would cover them. For instance, copy/cut/paste is covered by ClipboardEvent. Selection is covered by BeforeSelectionChange. Would undo make sense in beforeinput or command? What about typing? What about the importance of Scrolling events for Accessibility, where do they land?

Our next step should be to take the scenarios we have outlined in the Explainer and come up with all Intensions that need to be captured. Then we can bucket them by event type and see if we’re missing anything.

Another argument against beforeInput is that ‘input’ covers a wide range of scenarios right now, including paste and drop. Paste and drop already have “intention” style events, so we might create redundancy or confusion.

I also agree that calling the event ‘beforeInput’ when no input is going to happen (in contentEditable minimal) might be confusing.

From: Piotr Koszuliński [mailto:p.koszulinski@cksource.com]
Sent: Wednesday, July 16, 2014 12:08 AM
To: Julie Parent
Cc: Ojan Vafai; public-editing-tf@w3.org<mailto:public-editing-tf@w3.org>
Subject: Re: Should we use BeforeInputEvent instead of CommandEvent?

To your list of arguments against BeforeInputEvent I would add one more. AFAIK, the InputEvent does not contain an information about the intention at all, so it's kind of a different family. On the other hand, my team was struggling recently with implementing an undo manager, because there's no single "after" event on which we can listen and reason on its basis. If both events -  BeforeInputEvent and InputEvent - contained information about intention that problem would be solved. On the third hand, in contenteditable=minimal an app will make a DOM changes by itself, so it does not need an "after" event.

If we want to design a pair of events to improve the situation on contenteditable=true, then choosing BeforeInputEvent and extending InputEvent may be a better choice. Adding BeforeInputEvent and not improving InputEvent at the same time in my opinion would look bad. In such case I would choose CommandEvent, because it will be easier to define.

On Wed, Jul 16, 2014 at 2:39 AM, Julie Parent <jparent@google.com<mailto:jparent@google.com>> wrote:
In order to move forward with specifying Command Events [1] in the Commands Explainer , we need to resolve issue 5: using BeforeInput vs adding a different CommandEvent.

This has been discussed on earlier threads without any consensus.

Arguments for using BeforeInput: InputEvent already exists and tracks input. BeforeInputEvent has been discussed already by DOM spec and the HTML spec, although not implemented by any browsers yet.  It doesn't make sense to add an additional event if BeforeInput will be moving forward.

Argument against: With contenteditable="minimal", nothing is actually going to be inserted, so BeforeInputEvent is not correctly named. BeforeInputEvent fires after other Intention Events like ClipboardEvent, so it will be double-handled. And it's not a clear corollary to the invoke side, which is currently execCommand.

Julie

[1] http://w3c.github.io/editing-explainer/commands-explainer.html#command-events




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com

--
Follow CKEditor on: Twitter<http://twitter.com/ckeditor> | Facebook<http://www.facebook.com/ckeditor> | Google+<https://plus.google.com/107736718646302128806> | LinkedIn<http://www.linkedin.com/company/cksource>