
Pointing the Way Forward - sagadotworld
https://developers.google.com/web/updates/2016/10/pointer-events?utm_source=feed&utm_medium=feed&utm_campaign=updates_feed
======
niftich
Finally!

'Pointer events' originated at Microsoft, after the W3C effort to standardize
Apple's 'Touch events' became uncertain due to patent issues. For a while,
despite admitting it's a more elegant spec for unified input, Google were
reluctant to add it because Apple wasn't interested [1][2].

Now Google have changed their mind once more and shipped this, making Apple
the only major outlier. The pains of shimming these similar-but-different APIs
will continue for a bit, but hopefully Apple will make this concession in the
end.

[1] [https://timkadlec.com/2015/02/apples-
web/](https://timkadlec.com/2015/02/apples-web/)

[2] [https://mobiforge.com/news-comment/who-wants-pointer-
events-...](https://mobiforge.com/news-comment/who-wants-pointer-events-api-
everyone-nearly)

~~~
pkulak
How difficult would a TE -> PE library be to build?

~~~
bsimpson
You mean like this one?

[https://github.com/jquery/PEP/](https://github.com/jquery/PEP/)

Was built by the Polymer team before Chrome deprioritized Pointer Events the
first time round, and transferred to the JQuery Foundation thereafter.

~~~
pkulak
Good to know. Thanks!

------
pimlottc
> Ever spent a frustrating hour debugging a broken mouseup event, until you
> realised that it’s because the user is letting go of the button outside your
> click target? No? Okay, maybe it’s just me, then.

I hope no one uses this example to make an onClick action that works no matter
where the pointer is when the button is released. The correct behavior when
this happens is to ignore the click when the user has moved off the click
target when the button is released. It's a pretty handy convention, as it's
the only way to for a user to "abort" a click once they start it - something
I've done a few times myself.

This example pattern could be useful, though, in managing the UI state when
something like this occurs.

~~~
erikpukinskis
The problem, as I understand it, is in order for a UI to feel responsive you
often have to start reacting to the mousedown/mousemove before the mouseup
occurs. So you need to do some cleanup when that mouseup event happens. Only
you never got a mouseup event because it happened over some other random
element.

------
Analemma_
I was one of the people who was really raging at Google when they announced
that Chrome wouldn't support PE (with that infamous "No argument that PE is
more elegant" comment), so it's only fair that I thank them sincerely for them
doing the right thing and making a 180 on this. Good job.

------
riskable
In anticipation of this day I added support for PointerEvents to HumanInput
months ago:

[https://github.com/liftoff/HumanInput](https://github.com/liftoff/HumanInput)

It really is a superior way to handle mouse and touch (and stylus!) events. If
you look at pointer.js in the repo you can see how much simpler it is to
handle PointerEvents VS the combination of traditional mouse and touch events.

------
DubiousPusher
Back in 2012 with the roll out of the Surface, we wrote our own translation
layer to handle unifying mouse+touch input for a game we were working on that
never made it to launch.

It's one of those things you just shouldn't have to write. This probably makes
a lot of web devs very happy.

------
stoikerty
It's hard to describe just how happy I am to see this! Plus they gave us a
free polyfill. f'ing awesome

