5 ms·

Pointing the Way Forward

96 points by sagadotworld 10y ago

niftich 10y ago
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-api-everyone-nearly https://mobiforge.com/news-comment/who-wants-pointer-events-...
- Klathmon 10y ago
  >making Apple the only major outlier That does seem to be a theme with web technologies and Apple recently. I hope their recent work on Safari 10's compatibility continues.
- pkulak 10y ago
  How difficult would a TE -> PE library be to build?
  - bsimpson 10y ago
    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 10y ago
      Good to know. Thanks!
  - riskable 10y ago
    This one has you covered ;) https://github.com/liftoff/HumanInput https://github.com/liftoff/HumanInput Wrote it myself.
Analemma_ 10y ago
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.
DubiousPusher 10y ago
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 10y ago
It's hard to describe just how happy I am to see this! Plus they gave us a free polyfill. f'ing awesome
riskable 10y ago
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.
pimlottc 10y ago
> 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 10y ago
  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.

96 points by sagadotworld 10y ago

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-api-everyone-nearly https://mobiforge.com/news-comment/who-wants-pointer-events-...

Klathmon 10y ago
>making Apple the only major outlier That does seem to be a theme with web technologies and Apple recently. I hope their recent work on Safari 10's compatibility continues.
pkulak 10y ago
How difficult would a TE -> PE library be to build?
- bsimpson 10y ago
  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 10y ago
    Good to know. Thanks!
- riskable 10y ago
  This one has you covered ;) https://github.com/liftoff/HumanInput https://github.com/liftoff/HumanInput Wrote it myself.

Analemma_ 10y ago

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.

DubiousPusher 10y ago

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 10y ago

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

riskable 10y ago

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.

pimlottc 10y ago

> 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 10y ago
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.