> Their stated rationale was that because Apple was unlikely to ever support Pointer Events and Apple is the dominate force in the mobile web; Touch Events would always be required.
Very briefly, pointer events has 3 main drawbacks relative to the alternative:
1) 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.
2) 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.
3) 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 ).
That's only one of their reasons.
https://code.google.com/p/chromium/issues/detail?id=162757#c...
https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2...
In particular, see the notes in slide 6. They have several reasons that include performance, flexibility, and compatibility.