4 ms·

* Added support for the Pointer Events API enabling consistent access to mouse, trackpad, touch, and Apple Pencil events. https://caniuse.com/#feat=pointer htt

* Added support for the Pointer Events API enabling consistent access to mouse, trackpad, touch, and Apple Pencil events. https://caniuse.com/#feat=pointer https://caniuse.com/#feat=pointer - now you can use one unified event capture everywhere, instead of having to choose between "click" and "touch"!

ilkkao 7y ago
Nice to see that all browsers support Pointer Events now. This Microsoft proposed standard was initially fiercely opposed by Google and Apple some years ago.
- cptskippy 7y ago
  Well that was before they were shipping devices with a stylus.
robocat 7y ago
Mostly you can just need a click event now since "fastclick" can now work on all modern devices (albeit may need meta viewport or CSS). In my experience writing a component suite I have found I don't use touch[a-z]+ events that much (just like mouse[a-z]+ events don't get used much either). I would be very careful before believing the promise of Pointer Events, unless you need to be on the bleeding edge for some reason. When I first used Pointer Events, there were heaps of corner cases that bit me hard. I would be especially careful if using them with virtual Dom updates or very dynamic pages - one of the worst pain points was issues with events when elements were deleted/replaced.
- SeanAnderson 7y ago
  I'm currently rewriting a legacy application to use Pointer Events + pepjs polyfill. Your experiences don't align super well with mine. I'm curious as to why. What does vdom diffing / dynamic page content have to do with using pointer/touch/mouse events? If anything, the last scenario you describe sounds like it would be mitigated by use of https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set... which is only available to PointerEvent implementations?
  - robocat 7y ago
    I found setPointerCapture() caused multiple bugs in corner cases (including one regression a while ago that completely broke our touch support in Chrome desktop). Maybe the support has improved in Chrome and Firefox, but I would be very careful to test Safari support before I relied 100% upon Touch Events.
jancsika 7y ago
The Pointer Events spec is a real joy. For example, if you want to roll your own "drag" event for a given element, the API allows you to do this without reference to document or a parent container element. You can just declare that the element currently receiving pointer events capture subsequent pointer events until you release it[1]. Additionally, the API naturally lends itself to patterns that can easily be extended for multi-touch situations. I'm quite curious which developer led the charge for this API and how they warded off committee meddling by people who lacked knowledge about the benefits of this approach. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set...

ilkkao 7y ago

Nice to see that all browsers support Pointer Events now. This Microsoft proposed standard was initially fiercely opposed by Google and Apple some years ago.

cptskippy 7y ago
Well that was before they were shipping devices with a stylus.

robocat 7y ago

Mostly you can just need a click event now since "fastclick" can now work on all modern devices (albeit may need meta viewport or CSS). In my experience writing a component suite I have found I don't use touch[a-z]+ events that much (just like mouse[a-z]+ events don't get used much either). I would be very careful before believing the promise of Pointer Events, unless you need to be on the bleeding edge for some reason. When I first used Pointer Events, there were heaps of corner cases that bit me hard. I would be especially careful if using them with virtual Dom updates or very dynamic pages - one of the worst pain points was issues with events when elements were deleted/replaced.

SeanAnderson 7y ago
I'm currently rewriting a legacy application to use Pointer Events + pepjs polyfill. Your experiences don't align super well with mine. I'm curious as to why. What does vdom diffing / dynamic page content have to do with using pointer/touch/mouse events? If anything, the last scenario you describe sounds like it would be mitigated by use of https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set... which is only available to PointerEvent implementations?
- robocat 7y ago
  I found setPointerCapture() caused multiple bugs in corner cases (including one regression a while ago that completely broke our touch support in Chrome desktop). Maybe the support has improved in Chrome and Firefox, but I would be very careful to test Safari support before I relied 100% upon Touch Events.

jancsika 7y ago

The Pointer Events spec is a real joy. For example, if you want to roll your own "drag" event for a given element, the API allows you to do this without reference to document or a parent container element. You can just declare that the element currently receiving pointer events capture subsequent pointer events until you release it[1]. Additionally, the API naturally lends itself to patterns that can easily be extended for multi-touch situations. I'm quite curious which developer led the charge for this API and how they warded off committee meddling by people who lacked knowledge about the benefits of this approach. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set...