Intent to Implement: Pointer Events

1,175 views
Skip to first unread message

Scott Blomquist (MS OPEN TECH)

unread,
May 13, 2013, 7:57:27 PM5/13/13
to blink-dev

Primary eng (and PM) emails

sb...@microsoft.com; afor...@microsoft.com; asir...@microsoft.com; rby...@google.com
 

Spec

http://www.w3.org/TR/pointerevents/

 

Summary

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.

OWP launch tracking bug?
crbug.com/196799

 

Row on feature dashboard?
Yes

 

Requesting simultaneous permission to ship?

No. Our immediate goal is to perform interoperability testing with other browser implementations and surface spec issues to route back to the W3C.

 

--

Scott Blomquist

Senior Development Lead

Microsoft Open Technologies, Inc.

A subsidiary of Microsoft Corporation

 

Kenneth Rohde Christiansen

unread,
May 14, 2013, 3:02:09 AM5/14/13
to Scott Blomquist (MS OPEN TECH), blink-dev
lgtm, it is cool that this is getting some traction.

Kenneth
--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

Dimitri Glazkov

unread,
May 14, 2013, 12:56:28 PM5/14/13
to Kenneth Rohde Christiansen, Scott Blomquist (MS OPEN TECH), blink-dev
Big fan, excited to see this happening.

:DG<

Darin Fisher

unread,
May 14, 2013, 1:13:54 PM5/14/13
to Scott Blomquist (MS OPEN TECH), blink-dev
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 can imagine that an alternative path would be to simply point web developers at https://github.com/toolkitchen/PointerEvents while we work to develop the C++ implementation of Pointer Events.

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

-Darin

Adam Barth

unread,
May 14, 2013, 2:40:37 PM5/14/13
to Darin Fisher, Scott Blomquist (MS OPEN TECH), blink-dev
On Tue, May 14, 2013 at 10:13 AM, Darin Fisher <da...@chromium.org> wrote:
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.
 
I can imagine that an alternative path would be to simply point web developers at https://github.com/toolkitchen/PointerEvents while we work to develop the C++ implementation of Pointer Events.

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

Me too.  :)

Adam

dustan...@gmail.com

unread,
May 17, 2013, 8:55:16 AM5/17/13
to blin...@chromium.org
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 ;)

Rick Byers

unread,
May 17, 2013, 12:18:20 PM5/17/13
to dustan...@gmail.com, blink-dev
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.

Seem reasonable?

dustan...@gmail.com

unread,
May 20, 2013, 8:44:12 AM5/20/13
to blin...@chromium.org

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.

tilo...@gmail.com

unread,
May 20, 2013, 5:05:02 PM5/20/13
to blin...@chromium.org
+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?

Rick Byers

unread,
May 24, 2013, 2:20:07 PM5/24/13
to tilo...@gmail.com, blink-dev
On Mon, May 20, 2013 at 5:05 PM, <tilo...@gmail.com> wrote:
+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.

But you can start playing with the polyfills today, eg: http://polymer-project.appspot.com/platform/pointer-events.html.  These polyfills should get better (more faithful to the spec and more performant) as native browser support becomes more broadly available.

Rick
Reply all
Reply to author
Forward
0 new messages