Finally!<p>'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].<p>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.<p>[1] <a href="https://timkadlec.com/2015/02/apples-web/" rel="nofollow">https://timkadlec.com/2015/02/apples-web/</a><p>[2] <a href="https://mobiforge.com/news-comment/who-wants-pointer-events-api-everyone-nearly" rel="nofollow">https://mobiforge.com/news-comment/who-wants-pointer-events-...</a>
> 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.<p>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.<p>This example pattern could be useful, though, in managing the UI state when something like this occurs.
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.
In anticipation of this day I added support for PointerEvents to HumanInput months ago:<p><a href="https://github.com/liftoff/HumanInput" rel="nofollow">https://github.com/liftoff/HumanInput</a><p>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.
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.<p>It's one of those things you just shouldn't have to write. This probably makes a lot of web devs very happy.