Re: [clipboard] kill onbefore* events?

On Wed, Mar 9, 2016 at 3:40 PM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

>
> On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик)
> <garykac@chromium.org> wrote:
>
> > There is a design tension between the 2 extreme approaches, each with
> pros
> > and cons:
> >
> > (1) A single 'beforeinput' event that fires for all "input" activities.
> > Pros: Developers only need to support this and don't worry about the
> > details. Basic support for new input types just work without additional
> > work.
>
> I don't see how this logic holds if you add something like beforeInput
> for paste. Suppose that I already wrote a beforeInput - based editor.
> Suppose it's pretty good at handling the events I already know - I've
> carefully implemented typing, deletion etc based on beforeInput
> events. Now all of a sudden a modern browser is sending me beforeInput
> with eventType set to "paste" and with an event.clipboardData property
> I'd have to pull data from to insert into the DOM to make the paste
> work. How is that something that will "just work" in my app? It
> clearly won't.


Unless the `beforeinput` event is canceled, the DOM will be updated without
any special handling. Most webapps don't need to do anything to support
typing, deletion, et al, and they wouldn't need to do anything to support
paste. A rich editing app may need/choose to do extra work, but pasting
into a regular <input type="text"> should work without any extra effort.

Consider `beforeinput` (as it replaces `keypress`):
* `beforeinput` event is sent with key info. If I ignore it, the DOM will
be updated with the key value, if I cancel it, it doesn't. If the
programmer does nothing, key presses just work.

Now a paste action happens:
* `beforeinput` event is sent with the paste data (just in case the app
wants to do something with it). If ignored, the DOM will be updated, If
canceled, the DOM won't be updated. If the programmer does nothing, pasting
just works.

Now a brand-new-event-that-updates-the-DOM is sent:
* Same thing. `beforeinput` event is sent. DOM is updated (or not, if
canceled). It just works.

In fact, that's pretty much how the Clipboard API spec says the 'paste'
event should work:

7.1.3 The paste action

If the cursor is in an editable element, the paste action will insert
> clipboard data in the most suitable format (if any) supported for the given
> context.


This means that it updates the DOM, which means that a `beforeinput` event
needs to fire.  And if we're firing a cancelable `beforeinput` event, then
there's no point also sending a `paste` event that does basically the
thing. This is the exact same situation that we had with `keypress` and it
was deprecated in favor of `beforeinput`.