Blink does not plan to implement pointer events

We've discussed on our conference calls the progression of the blink team's
thinking around pointer events as it developed over the past year and a
half (with conclusions mostly recently
<http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0118.html>
after the web-input face-to-face).  But I realized I should send a clear
announcement to this list for people that haven't been following the
meeting notes.  I've now officially marked support for pointer events in
blink <https://code.google.com/p/chromium/issues/detail?id=162757> as
WontFix with the below note.

I apologize that we didn't have the foresight to see where this would lead
when we started down this pointer events journey together 2 years ago.  The
main shift in thinking for us has been from a position of a
desktop-dominated web evolving slowly to enable mobile scenarios, to the
realization that phones/tablets will soon dominate Internet usage and that
the web is loosing to native mobile platforms.  I've tried hard to be
completely transparent on our thinking as it evolved, and I really value
all that we've learned and the relationships we've built.

I plan to continue to participate in the working group, as the problems
we're trying to solve are essentially the same regardless of the specific
form of the API and we have at least the touch-action API in common.  I
hope it goes without saying that this decision reflects only a difference
in technical opinion about what's best for the long-term health of the web
platform. The blink team continues to be deeply committed to evolving the
platform only through the collaboration of multiple browser vendors and the
web standards process.  We have deep respect for the work Microsoft has
done here, and I'm optimistic that we will find a way together to leverage
the advancements in input API design without the drawbacks of introducing a
new event model (I'll start a discussion of one possible path on the
public-touchevents list shortly).

Thanks,
   Rick

---
After tons of debate and discussion, with lots of great input from our
friends on the IE, Firefox and Safari teams, we've decided that
incrementally extending our existing input APIs (see issue 404128
<http://crbug.com/404128>) is a better path forward for blink (and, we
believe, the web) than adopting pointer events.

See a summary of our position here:
https://docs.google.com/a/chromium.org/presentation/d/1qRqLKQjOnGgrM-UkMAb2RH6mQCFQHk8R01s5qvjm2Po/edit#slide=id.g355c5631f_134

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 ).

We're committed to working in the web standards community to improve input
on the web, and we especially value the relationship we've recently built
up with the IE team here.  Despite this difference in technical opinion on
what's best for the web, I'm optimistic that we'll still make good progress
together.