Re: [clipboard] kill onbefore* events?

On Thu, Mar 10, 2016 at 12:40 AM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> > Just using mutation observers, one can see the change that was made, but
> > doesn't really know what the user's intentions were, right?
>
> I guess so, haven't used them for anything. Perhaps the "after the
> fact" nature was a design flaw in Mutation Observers.
>
> > The browser meeting also came up with the suggestion that drag-and-drop
> > should have a beforeinput event [1].
>
> I'd prefer not..
>
> >> 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?
>
> My suggestion would be to use the existing stuff for clipboard and
> DnD: a developer with a cE=events editing host who is interested in
> enabling paste should listen to paste events. If she wants to enable
> DnD she should listen to drop events. And of course a beforeInput
> listener for the stuff that beforeInput does best.
>

For us JavaScript people this alternative would be a few more lines of
code, but not impossible to handle.

I think this is mostly for the browser people to come to an agreement about.

>
> > 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.
>
> Easier to read because there's less if() branching and switch() statements.
>

You mean in the JavaScript code? Well, it will be maybe three-four event
more event handlers and then maybe 25 cases in the beforeInput/input event
handler.

Either way will work, but I don't think either one will be much less or
more code than the other. Also if I just wanted to listen to for example
"paste", "insertCharacter" and "deleteForward" or soem other subset, it
doesn't seem very hard handler to create the correct switch statement.


> Easier to debug because if you want to debug pasting, you ask your
> debugger to break on a paste event. No scanning through lots of code
> in a code base you may not even know to find the right beforeInput
> method sub-branch to break on. Not breaking on beforeInput and
> striving to trigger a paste without doing anything else that will
> trigger the breakpoint set on an event that fires for quite a few
> things. (Ever tried to debug a problem in a mousemove event handler? I
> have..more than once.)
>

I assume you are here thinking of the debugging issues it gives in the
browser code. This I know nothing about.

In the JS code I cannot see why this wouldn't be solveable by filtering
through the events with a switch and then just debugging the part of the
code that is executed for a specific action.


>
> Using more narrowly scoped events for those things that require
> special payloads or API just seems a lot better. I actually think you
> should push back a bit against the browser devs who seem to think
> beforeInput is the perfect hammer for anything that might or might not
> resemble a nail..
>

:)

I think it will work for us JS-ppl either way. The most important is that
the browser-people come to an agreement.

The beforeinput approach makes it slightly easier to just listen to one
event and learn all about that and have all the edit types in just one
document, rather than having to hunt down all the different events in
different documents and never being entirely sure all user intentions are
really handled.

The separate events approach may mean that this is implemented faster
because the clipboard and drag/drop events don't have to be changed (right?)

I can ask around the different editor developers, but it seems to me that
this likely isn't an issue any of the JS editor people would want to fight
with any of the browser people.

So it would be good if Firefox could come to an agreement with the other
browser developers. Also, it would be good if Firefox could be represented
at the next Editing Taskforce meeting. I sent aa proposal out to our
mailinglist a few days ago of having the next meeting around May/June and
then perhaps TPAC.


>
> (I'm responding to some of Gary's points in the next reply on this thread
> below)
>
> On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик)
> <garykac@chromium.org> wrote:
>
> >> 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.
>
> I agree it's a trade-off - in other words we're discussing shades of grey.
>
> > 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.
>
> > Cons: Developers that care only about a particular type need to filter
> out
> > the other event types.
>
> <X>
>
> > (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.
>
> But the same thing can easily happen with a single-event model where
> developers (naturally) "filter out" event types they believe they are
> not interested in.. If four years from now browsers start sending me
> "beforeInput" of type "voiceRecognition" I may have written lots of
> code handling all the other already known input types and my app is
> going to be broken when used with voice.
>
> Now, of course I think the idea here is to up the semantic value of
> the events so you get "this text is being inserted" semantics (even
> for voice..) that's easy to handle compared to a "those keys were
> pressed and we have a number that might look like a key you think you
> know but might not and we won't tell you more" semantics of keypress.
> But that's sort of independent of the question of whether to have a
> single-event or multiple-events model. If you really want to be
> backwards compatible you could spell out the letters of the words from
> voice recognition and send keydown/up/press and good, old input and
> change events.. wonder if we're actually going to go there when we get
> that far ;)
>
> > 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.
>
> What if those options do not correspond to the two alternatives we're
> discussing? :) You might see something I don't, but I think we're
> conflating a few issues here.
> -Hallvord
>



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