Re: [clipboard] kill onbefore* events?

On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm <> wrote:

> Once I get back to work, I will start to program a version 5.0 of my editor
> that handles the new eventtype correctly.
> Anyone still not having upgraded from version 4.35, the editor doesn't end
> up doing crazy/uncontrolled stuff when receiving voice input. It simply does
> nothing on voice input

That's sort of the polar opposite of Gary's goal that new stuff should
"just work" :)

It also means that you do *not* consider it a goal of your spec
development to make it easier to handle stuff the developer hasn't
explicitly thought of - like IMEs, accessibility helpers and possible
future input stuff - in a way that would have a chance of "just

I'd consider it a brilliant technological achievement if voice input
fired key insertion beforeInput events (and potentially
keydown/up/press - why not? /me <3 back compat :-p) and your app "just
worked" with the new Apple device while you were scuba diving (and
more importantly: on the 10 000 sites that never bothered updating to
the new version of your JS lib at all).

Anyway - however much fun we can have imagining the future, this
discussion is sort of off-topic when we're arguing whether to replace
specialised paste and drop events with a general beforeInput
eventType=paste and eventType=drop approach.

Johannes also wrote:

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

25 cases is a lot :)

>> Easier to debug because if you want to debug pasting, you ask your
>> debugger to break on a paste event.

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

Not meant as boasting but just to explain where I'm seeing things
from: I've been debugging random issues on random websites for the
last 14 years or so, usually working on code I have not had the luxury
of prior knowledge of, I've been dissecting heavily obfuscated code at
least since GMail hit the web. 25+ cases inside one event handler
inside an obfuscated script is hard. 25+cases inside a non-obfuscated
script still means you might have to step over quite a few statements
to get to the code you want to see running.

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

Browser people who advocate for this solution should be tasked with
creating a usable debugger UI for this :)
Most debuggers already have UI for breaking on a specific event type.
This is a solved problem. None have UI for creating conditional
breakpoints on a specific event type AFAIK - not saying it can't be
done, but it's harder.


Received on Thursday, 10 March 2016 09:51:47 UTC