Re: [clipboard] kill onbefore* events?

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

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

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

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

Received on Wednesday, 9 March 2016 23:41:31 UTC