Re: [clipboard] kill onbefore* events?

On Wed, Mar 9, 2016 at 5:29 AM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик)
> <garykac@chromium.org> wrote:
>
> > Agreed. That is the major benefit of 'beforeinput' and 'input' -- you
> will
> > receive a 'beforeinput' event just before any DOM update (with an option
> to
> > cancel it), and you'll also receive an 'input' event just after the DOM
> was
> > updated.  If you want to track all DOM updates, then you only need to
> listen
> > to these two events.
>
> In my personal (and humble) opinion it's not actually a benefit for
> developers to have only one event that will fire a lot and indicate
> lots of different things. I accept that library authors want a
> convenient "point of overview" regarding what happens in the DOM (but
> wasn't mutation observers supposed to do that job?). However, making
> one single event type carry lots of different information and adding
> stuff like clipboardData and/or dataTransfer (because drag-and-drop
> changes the DOM too, right?) to the InputEvent interface seems like we
> force authors to
>
> 1) Write code with lots of if(e.eventType === foo) and
> switch(e.eventType) branching, which is hard to read
> 2) Debug code that gets run a lot all the time - event loops that fire
> often are annoying when debugging
>

Yes, that's one of the trade-offs that needs to be considered when
designing these APIs.

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.
Cons: Developers that care only about a particular type need to filter out
the other event types.

(2) Separate events for each type of input activity.
Pros: Developers that care about specific event types can easily catch the
cases they care about.
Cons: Developers have to explicitly add support for each event type if they
want to catch all input.

(Hybrid approaches are also possible: add some more specific events + a
generic catch-all, but that means a lot more events are being sent.)

There are issues with either approach:
(1) Problem with single event: Anne mentioned XMLHttpRequest
readystatechange as an example of going too far down the path with a
generic "something-happened" event.
(2) Problem with separate events: Many developers didn't support
composition events because their native language didn't use them, so parts
of the web were broken for CJK users. We don't want similar things to
happen for voice or accessibility (or other) inputs. Note that this is part
of the reason why 'keypress' was deprecated.

Personally, I'm more concerned about developers forgetting to add (or not
knowing they need to add) support for uncommon things like IMEs, voice and
accessibility, than I am about a developer sometimes needing to write a bit
of extra code to filter out things they're not immediately interested in.
The latter is an inconvenience for the developer, but the former breaks
part of the web for some users.