The proposed API implements the Pointer Events spec that just graduated to Candidate Recommendation in W3C. As part of that, a first step will be to
implement the touch-action feature in C++, which will also be leveraged to improve the experience for the currently supported Touch Events API. In parallel, through a separate runtime flag from touch-action, we will provide the remaining Pointer Events API
surface through a JavaScript polyfill so that developers can start experimenting with the full API while we implement the other Pointer Events features in C++.

Motivation

Pointer Events elegantly unifies the interface for different input technologies (mouse, touch, pen) thereby simplifying developer workload and code complexity.
Furthermore, it automatically addresses common coding challenges for increasingly ubiquitous device types that allow multiple types of input at the same time. It provides a future-proof abstraction that will allow Pointer Events-enabled web pages to leverage
any new input technologies with little if any modifications at all.The API is already supported by Internet Explorer.

The touch-action feature will also benefit the existing Touch Event API by addressing a commonly reported complain re: scrolling jerkiness, which cannot be worked
around with the existing API.

Compatibility Risk
Low. This API provides new functionality and it should not break existing behaviors. Steps will be taken prior to check in to ensure that existing input behaviors are thoroughly tested and do not incur into regressions.

Can you comment on what it means to "ship" a JavaScript polyfill behind a flag in Chromium? To the best of my knowledge, this is a new thing for us. We don't have any established machinery to support such a thing. Is there a design for how this will be done?

Can you comment on what it means to "ship" a JavaScript polyfill behind a flag in Chromium? To the best of my knowledge, this is a new thing for us. We don't have any established machinery to support such a thing. Is there a design for how this will be done?

I think the goal is to have a flag that automatically injects the polyfill. I agree it would be useful to have a design doc for that part.

Until Pointer Events are widely implemented (e.g., including Mobile Safari), developers will need to use a polyfill. When we're encouraging developers to use Pointer Events, we should point them towards a particular polyfill that works well.

Before implementing Pointer Events in C++, I'd like to see more demand for Pointer Events in the form of developers using Pointer Events via polyfills. At that point, implementing Pointer Events becomes "just" a performance optimization. Having a polyfill that can be enabled as a runtime flag puts pressure on us to make sure the polyfill is both correct and performs well.

(I'm a big fan of implementing touch-action separately and up-front by the way!)

The proposed API implements the Pointer Events spec that just graduated to Candidate Recommendation in W3C. As part of that, a first step will be to
implement the touch-action feature in C++, which will also be leveraged to improve the experience for the currently supported Touch Events API. In parallel, through a separate runtime flag from touch-action, we will provide the remaining Pointer Events API
surface through a JavaScript polyfill so that developers can start experimenting with the full API while we implement the other Pointer Events features in C++.

Motivation

Pointer Events elegantly unifies the interface for different input technologies (mouse, touch, pen) thereby simplifying developer workload and code complexity.
Furthermore, it automatically addresses common coding challenges for increasingly ubiquitous device types that allow multiple types of input at the same time. It provides a future-proof abstraction that will allow Pointer Events-enabled web pages to leverage
any new input technologies with little if any modifications at all.The API is already supported by Internet Explorer.

The touch-action feature will also benefit the existing Touch Event API by addressing a commonly reported complain re: scrolling jerkiness, which cannot be worked
around with the existing API.

Compatibility Risk
Low. This API provides new functionality and it should not break existing behaviors. Steps will be taken prior to check in to ensure that existing input behaviors are thoroughly tested and do not incur into regressions.

Before implementing Pointer Events in C++, I'd like to see more demand for Pointer Events in the form of developers using Pointer Events via polyfills.

As a web developer greatly interested in pointer events being implemented in browsers, I would like to just add that none of the polyfills are really great solutions currently. A number of them don’t support all elements or browsers due to hijacking the `addEventListener` method. I have been cycling through the available polyfills (previously https://github.com/borismus/pointer.js and toolkitchen/pointerevents.js; now adding hand.js to the mix) and have found them to be lacking as a drop-in and go for the projects I’ve been working on (namely in SVG).

I am extremely excited to see this come to Blink and will be pushing all the devs around me to start using PointerEvents as soon as there is reasonable support in browserland. The chicken and the egg. We just want opposites to come first ;)

On Fri, May 17, 2013 at 5:55 AM, <dustan...@gmail.com> wrote:
>> Before implementing Pointer Events in C++, I'd like to see more demand for
>> Pointer Events in the form of developers using Pointer Events via polyfills.
>
>
> As a web developer greatly interested in pointer events being implemented in
> browsers, I would like to just add that none of the polyfills are really
> great solutions currently. A number of them don’t support all elements or
> browsers due to hijacking the `addEventListener` method. I have been cycling
> through the available polyfills (previously
> https://github.com/borismus/pointer.js and toolkitchen/pointerevents.js; now
> adding hand.js to the mix) and have found them to be lacking as a drop-in
> and go for the projects I’ve been working on (namely in SVG).
>
> I am extremely excited to see this come to Blink and will be pushing all the
> devs around me to start using PointerEvents as soon as there is reasonable
> support in browserland. The chicken and the egg. We just want opposites to
> come first ;)

Yes, this is definitely a problem. We're going to do two things about
this in parallel.

First we're going to work with the various polyfills (or create our
own if necessary) to ensure there is one that we can recommend as
being highly spec compliant, and production ready in terms of
performance/reliability/etc. Unfortunately there are hard tradeoffs
to be made today, so those competing goals may have to be realized by
separate polyfills or different modes of one polyfill.

Secondly we're going to start adding experimental support to Chrome to
make great PE polyfills easier. In particular, as Scott described
we'll start with the touch-action CSS property (new CSS properties are
notoriously hard to polyfill).

My hope is that this will leave us in a place where we have a great
polyfill experience on Chrome and IE 10, and a workable experience on
other browsers (perhaps with performance trade offs, or requiring some
additional hacks in your application like Polymer/ToolKitchen's
approach of using html attributes instead of CSS for touch-action).
Then we should be able to get enough real-world usage to decide
whether to ship native PE support in Chrome.

My hope is that this will leave us in a place where we have a great polyfill experience on Chrome and IE 10, and a workable experience on other browsers

That definitely sounds reasonable. I understand the complexities involved and the trade offs necessary. I’d rather see it done right with opportunity to experiment before tying down it and shipping it gung-ho.

+1!! I'm really glad to see this development. It is unrealistic and difficult for the average web developer to have multiple event listeners, listening for `touch*` events along with `mouse*` events, and preventing default behavior on one to prevent the other. It's too complicated for someone who is not using a library or a polyfill. Add to this, the fact that we have multiple ways to subscribe to events (addEventListener() vs attachEvent() in OldIE), and you quickly get into a messy place regarding event subscription.

Currently, JS libraries have to manage this in an attempt to provide developers with a higher-level API. This is something that we are working on at YUI @ Yahoo. (https://github.com/yui/yui3/issues/683).

The Pointer API in IE10 does a great job of creating a common interface for various inputs. I strongly believe that something like this should be baked into the other browsers.

Any timelines on when we can start playing with something like this in Canary?

+1!! I'm really glad to see this development. It is unrealistic and difficult for the average web developer to have multiple event listeners, listening for `touch*` events along with `mouse*` events, and preventing default behavior on one to prevent the other. It's too complicated for someone who is not using a library or a polyfill. Add to this, the fact that we have multiple ways to subscribe to events (addEventListener() vs attachEvent() in OldIE), and you quickly get into a messy place regarding event subscription.

Currently, JS libraries have to manage this in an attempt to provide developers with a higher-level API. This is something that we are working on at YUI @ Yahoo. (https://github.com/yui/yui3/issues/683).

The Pointer API in IE10 does a great job of creating a common interface for various inputs. I strongly believe that something like this should be baked into the other browsers.

Thanks for your support Tilo!

Any timelines on when we can start playing with something like this in Canary?

It's too early to say when (or if) a full pointer-event solution will be available in canary. But I'm actively working on supporting touch-action (crbug.com/241964), which I believe is the one piece preventing great spec-compliant polyfills. There's a lot of work to be done though (some pretty major changes to how we process touches), so I wouldn't expect a complete touch-action implementation to be available behind the --enable-experimental-webkit-features flag for at least another month or so.

The proposed API implements the Pointer Events spec that just graduated to Candidate Recommendation in W3C. As part of that, a first step will be to
implement the touch-action feature in C++, which will also be leveraged to improve the experience for the currently supported Touch Events API. In parallel, through a separate runtime flag from touch-action, we will provide the remaining Pointer Events API
surface through a JavaScript polyfill so that developers can start experimenting with the full API while we implement the other Pointer Events features in C++.

Motivation

Pointer Events elegantly unifies the interface for different input technologies (mouse, touch, pen) thereby simplifying developer workload and code complexity.
Furthermore, it automatically addresses common coding challenges for increasingly ubiquitous device types that allow multiple types of input at the same time. It provides a future-proof abstraction that will allow Pointer Events-enabled web pages to leverage
any new input technologies with little if any modifications at all.The API is already supported by Internet Explorer.

The touch-action feature will also benefit the existing Touch Event API by addressing a commonly reported complain re: scrolling jerkiness, which cannot be worked
around with the existing API.

Compatibility Risk
Low. This API provides new functionality and it should not break existing behaviors. Steps will be taken prior to check in to ensure that existing input behaviors are thoroughly tested and do not incur into regressions.