Re: [clipboard] kill onbefore* events?

On Wed, Mar 9, 2016 at 2:29 PM, 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?).


Mutation observers look at actual changes in the DOM (for any reason).

The beforeinput event looks at the user's intention of changing something,
before the DOM is changed. The script can then take that information and do
whatever changes to the DOM that are needed.

In another setup, where one lets the browser do parts of the DOM changing,
the input event combined with the beforeinput event can let the script know
what the user intention was + what changes were made to the DOM based on
that intention. This may be helpful if the script needs to record this
change or make some additional changes to the DOM.

Just using mutation observers, one can see the change that was made, but
doesn't really know what the user's intentions were, right?



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


The browser meeting also came up with the suggestion that drag-and-drop
should have a beforeinput event [1].


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

What's your proposed alternative? That one creates a three event listeners
for the clipboard events +  one for beforeInput that covers most other
operations + maybe one for drag and drop? I don't see how that be easier to
debug or read, at least on the JavaScript side of things.


>
> My five cents..
> -Hallvord
>

[1] https://github.com/w3c/editing/issues/107

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org