From the Chromium developer mailing list:
Very briefly, pointer events has 3 main drawbacks relative to the
Mobile-first web: Pointer events would likely never supplant
touch events on the web (especially without support from
Safari). Since touch events are here to stay, supporting
another largely redundant input model has a high long-term
complexity cost on the web platform.
Performance: The hit testing model required by pointer events
imposes a non-trivial performance penalty (hit test on every
movement event) that neither Android, iOS or touch events has.
We’re not willing to add any feature that increases the web’s
performance disadvantage relative to native mobile platforms.
Richness: Pointer events requires that scrolling and event
handling are mutually exclusive. This precludes some UI effects
which are common on on mobile platforms (eg. pull to refresh).
Recently strong developer feedback has lead us to change Chrome
in the opposite direction here - enabling event handling while
scrolling (see issue 293467 ).
If there’s a performance hit and a decrease in expressible UI effects, it’s no wonder Apple and Google aren’t pursuing Pointer Events in WebKit or Blink. It’s not fair to categorize Google’s decision as simply “Because Safari won’t support it”. It’s a question of performance and user experience richness on one side, and developer convenience on the other.
★ Thursday, 26 February 2015