Re: Should we use BeforeInputEvent instead of CommandEvent?

Glad to see this getting resolved. I feel strongly that we should do
beforeinput and not commandevent.

On Wed, Jul 16, 2014 at 12:54 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

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

Yes. beforeinput and input should both have intention information and data
information (e.g. of the text that will get inserted).


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

Ignoring contentEditable=minimal for the moment, anything that would modify
the DOM should fire both a beforeinput event and an input event. We
*already* fire the input event in all these cases. So it's natural to
fire beforeinput in all those cases as well.

The important design point is that you should be able to listen to
beforeinput/input and capture all things that would modify the DOM.

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'm not too worried about this. We already have this situation with input
and key, paste, drop, etc. It doesn't cause problems or confusion. I don't
see why doing this with beforeinput would add confusion. Similarly, you can
capture undo events and you can capture ctrl+z using key events. I don't
see that causing confusion or problems.


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

The user did an input. Just because the default action is not to modify the
DOM with that input doesn't make it not an input. It's similar to how key
presses on a focused, non-editable element fire the key events even though
no character gets inserted.


>   *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
> *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> 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>
>