Pointing the Way Forward

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

[2] https://mobiforge.com/news-comment/who-wants-pointer-events-...

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.

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.

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