Pointer Events W3C Recommendation, Interoperable Touch, and Removing the Dreaded 300ms Tap Delay
Today, the W3C published Pointer Events as a final Recommendation standard. This journey began a little over 2 years ago when we first submitted our proposal to the W3C for a common event model across pointing input devices. Since then, the spec has evolved and improved with the collaboration of Mozilla, Google, Opera, jQuery, IBM, Microsoft Open Technologies, and many others. Improvements have included better extensibility for new device types, additional configuration values for scrolling and zooming behavior, event constructors for synthesizing custom pointer events, and more.
We updated and unprefixed our implementation in IE11. With the addition of DOM event constructors in the new rendering engine in the Windows 10 Tech Preview, our implementation is now 100% compliant with the W3C test suite. We’re also excited to see Firefox builds with 100% pass rate now with work underway to ship this to users soon. Additionally, jQuery, Dojo, and other open source contributors are now maintaining a faithful polyfill called “PEP” and intend to use this in jQuery UI, jQuery Mobile, and Dojo. With the polyfill, it’s possible to code to pointer events across browsers today.
We also continue to see great interest from Web developers lobbying for other browsers to implement (Pointer Events has more stars on Chrome’s issue tracker than 99.6% of all other tickets, open or closed). So we’re hopeful that other browsers will join us in advancing interoperability here.
Beyond Pointer Events, we’re also getting ready to update our new rendering engine with additional improvements for touch interoperability. Here’s a few of the changes you can anticipate and what you can do to take advantage of them.
Improving Touch Performance by Removing the 300ms Tap Delay
When modern browsers first came to mobile devices, there was an interesting problem. How do you make sites designed for a big desktop monitor work on a tiny screen? As a result, mobile browsers scaled Web pages in a (complicated) way to make it fit better. The double-tap gesture was then introduced to quickly zoom in and out of relevant content.
This solution provided a reasonable experience for sites that aren’t optimized for mobile. However, it comes with a tradeoff. From the perspective of a gesture recognizer, any single tap could be followed by another making it a double-tap instead. So before committing to the action of a tap (e.g. navigating a link or clicking a button), the browser must pause for a moment to see if another tap is right behind it. This introduces a noticeable delay (300ms) when you’re just tapping to activate something. This problem has been well documented and many fixes or workarounds have been proposed, including the popular FastClick library and others.
Starting in IE10 (and now in Chrome, coming soon to Firefox), sites could disable double-tap zoom with the CSS touch-action property from Pointer Events:
.disable300msDelay {
touch-action: manipulation;
}
Additionally in IE11, if you disable zoom altogether in your viewport rule (e.g. user-scalable: no) then this also disables the 300ms delay.
Now in the new engine, setting a viewport rule with a width less than or equal to the device-width (a strong signal that you’re not a desktop site we need to optimize for small screens) will also disable the 300ms delay. This results in significant performance wins for mobile sites.
Touch Interop Improvements
We recognize that not all browsers support Pointer Events, and so for interoperability we added Touch Events to Windows Phone 8.1 Update. In a future update to Windows 10, we’ll be improving the support in a few ways based on site compatibility and defacto behavior. We’ll also provide toggles in about:flags to enable/disable these changes to aid developers with testing.
Remove MSPointer events – we deprecated the experimental vendor-prefixed version of pointer events, MSPointer, in IE11. Now that unprefixed pointer events have been shipping for a while, we’re ready to remove MSPointer from the platform. Sites should update to use the standardized unprefixed events.
Fire touchmove during scroll – in Windows Phone 8.1, IE11 would fire a touchcancel event whenever a pan gesture was detected and scrolling begins (ending the event stream for that touch). Chrome recently changed to closer match Safari and we’re joining them. Now, touchmove events will continue to fire (asynchronously) during a scroll.
Simplify mouse events for touch – all modern touch browsers synthesize mouse events for touch in order to be more compatible with sites designed only with mouse in mind. IE previously used a more advanced algorithm for generating these events. However, oddly enough, many sites that use touch events also use mouse events and expect those to follow the webkit model. In this new model, only a tap gesture will produce mouse events (and the events produced are a predefined sequence that all fire at once: mousemove, mousedown, mouseup, click).
Support Touch Events for more devices – we’ve talked before about the compatibility issues resulting from supporting touch events on devices with a mouse. We’ve been working on outreach to sites to be more compatible with browsers supporting touch events on these types of devices. As a step towards touch events on all devices (regardless of input capabilities), we’re rolling out behavior where touch events are enabled on any device (desktop, tablet, or phone) that has a touch screen, which is how Chrome works today. In about:flags, you’ll be able to override this for testing and enable/disable touch events on any device.
There's a lot of positive changes here and we’d love your help in testing them. Look for these changes and more in updates to the Windows 10 Technical Preview and RemoteIE soon. We look forward love to hearing your feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.
— Jacob Rossi, Senior Program Manager, Project Spartan
Update (3/25/2015) - Google now intends to implement Pointer Events in Blink
Comments
Anonymous
February 24, 2015
Nice to see pointer events coming to other browsers! Great job guys! Hope to read more about project Spartan hint for next blog post? ;)?Anonymous
February 24, 2015
Glad to see Microsoft and Mozilla are forging ahead despite Google's backtrack on this. Fortunately, the polyfills work great even on Chrome and Safari, and I would have needed a library to help handle mixed mouse/touch events anyway - it might as well be a W3C recommendation with native support in at least two major browsers.Anonymous
February 24, 2015
Somehow it makes said to hear that such a more sophisticated algorithm was abandoned and in the end I am still not sure whether it was for the better but oh well…Anonymous
February 24, 2015
Being a member of the W3C Pointer Events Working Group I am, of course, biased...but having spent the last few years actively researching and documenting the often quite incongruous behaviour (and idiosyncratic "magic" heuristics) of Touch Event implementations across various platforms, and having seen first-hand the contortions that developers have to go through in order to create websites and applications that want to support both mouse and touch interactions, I am delighted to see that Pointer Events have advanced to official W3C Recommendation stage. Good effort, team :) (For a slightly longer comment/reaction, see www.paciellogroup.com/.../pointer-events-advance-to-w3c-recommendation)Anonymous
February 24, 2015
If I'm reading this right, developers are being given the option to disable double-touch-to-zoom functionality. I am concerned that some web sites might use it to disable double-touch zooming. Is the "manipulation" tag solve the delay while still supporting double touch content zooming?Anonymous
February 24, 2015
The comment has been removedAnonymous
February 25, 2015
The comment has been removedAnonymous
March 23, 2015
Apple's motivation is clear: If they make their browser a viable cross-platform and performant target platform for apps, they'll lose sales on the appstore. Simple economics.