Chrome Fires Its Big Gun At Pointer Events, Hurts Developers and End Users In the Process
Web development Jedi's felt a severe disturbance in the force Friday as the Evil Empire used its Chrome Death Star to attack the input modality system by blasting the planet Pointer Events. In case you did not feel the disturbance let me give you some insight. Friday the Chrome team announced they would not support Pointer Events a web standard that abstracts different user input modalities into a common, simple to utilize browser API. Currently Pointer Events are designed to abstract away classic mouse, modern touch and pen inputs. This means developers do NOT need to write separate code paths to handle each input modality's events.
The Pointer Events first appeared in Internet Explorer 10, using MS vendor prefixes. Soon after their initial appearance they were submitted to the W3C to be considered a standard other browser vendors, like Chrome, could implement. In one of the fastest processes I have witnessed in the W3C Pointer Events reached recommendation status last May.
What Are Pointer Events?
As I previously stated they combine mouse, touch and pen inputs into a single API. This makes it much easier for developers to write web applications that just work on any device without clumsy feature detection and unique code paths to properly react to each input's event model.
What are the alternatives to Pointer Events?
The path chosen by Apple and now Google is to force developers to write code to deal separately with each input's API. Traditionally this was not an issue as we had a single, indirect input modality that needed our attention, mouse. You may be familiar with click, mousedown, mouseover, mousemove, etc events. They have been staples of web development for two decades. But more and more the mouse is becoming a secondary choice to end users and the majority of computing devices purchased support touch.
Pen is another input type that is slowly growing in popularity. Both of my Surface Pro's came with a pen. As I write this post in Evernote I see an add in the bottom left corner for an Evernote pen. Handwriting and pen recognition is a very seductive input technology to consumers and enterprises alike. I think it is still a year or two from becoming ubiquitous. As a user experience developer I do not look forward to writing complex code to deal with pen input.
What do Pointer Events mean to the developer?
Because Pointer Events distill different input modalities into a single API it reduces the amount of code the developer needs to write, the user needs to download and the browser needs to interpret. In short it makes development easier and performance much better.
What is an Input Modality?
An input modality is the way the user interacts with a computer application. This can be indirect, like mouse or direct, like touch. Right now mouse and touch are the primary inputs, but pen and hand gestures are growing in coverage. Another area seeing rapid growth is voice. At first you may think voice might not work with pointers, but what if the system has built in commands to trigger things like select (tap/click), move (move/swipe), zoom in and out, etc. Today you can see the three core inputs across many devices, but we also need to think into the future and imagine other input techniques. A common API like Pointer Events makes the future much more aproachable, extending application life spans. That mean the future maintenance costs will be lower.
What Touch Libraries and Polyfils Exist?
There are three libraries I know of; HammerJs, HandJs and DeepTissueJS. Each of these provide way to either abstract the different APIs or polyfil Pointer Events in a browser that does not support them. HammerJS and DeeptissueJS provide an abstracted gesture interface. HandJS is a polyfil.
During the DeepTissue development process the majority of my frustration came from Chrome. Its touch support was almost non-existent outside of Android. And even on Android I found it to be tough sailing. To say I have not been happy with the way the Chrome team has addressed touch would be underselling my sentiment. Not only have they chosen to make it tougher for developers they are not offering a good experience for users. Unfortunately users do not understand it is a limitation of the browser platform, but accuse the application of not being written well. Somehow that is how it always works with Chrome.
Are Pointer Events Too Difficult to Implement?
Some might say the Chrome team does not have the resources to implement Pointer Events or they are too complicated to implement. Almost 18 months ago MSOpenTech created a WebKit prototype implementing Pointer Events. Of course it was a Beta, but doable and easily. In fact it was Microsoft that did the heavy lifting for Chrome.
So What Exactly Did the Chrome Team Say?
Last Friday it was brought to my attention the Chrome team finally made a public statement, after two plus years, they would not implement Pointer Events in response to issues reported to the Chromium project.
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.
1) Never say never. This summer Apple announced Safari is finally going to implement IndexDB, a storage technology that caused Apple's WebSQL storage to become deprecated. Apple finally realized IndexDB was better suited for the browser. Because Pointers abstracts different input types it is naturally positioned to replace Touch and Mouse. Of course mouse events would not be deprecated for a while, but I could easily see the mouse API become obsolete in a few years. A bold statement I know.
3) I honestly need to do some more research into the scroll and event handling scenario they are describing. Personally I have not felt any issues in any browser except Chrome. Maybe there are just some deficiencies in Chrome that make touch tougher to implement, I don't know.
Rather than implement Pointer Events (see issue 196799 ), we feel that the web will be better served by incrementally extending an API that's already in wide use. We see no credible path to replacing TouchEvents completely on the web, and so rather than introduce a new largely-redundant model to blink, we'd like to work within the web standards community to improve the APIs we have in a compatible way. Both Microsoft's PointerEvents and Android's MotionEvents provide abstraction across different input types and additional powers beyond what standard web MouseEvent and TouchEvent APIs provide. If we imagine a world 5-10 years from now where most internet usage is from phones and tablets, we think extending "touch" events to optionally enable a generic pointer input API will make sense. But of course this is highly debatable and something we need to continue to discuss within the web standards community and with other browser vendors. As always (http://www.chromium.org/blink#TOC-Policy-for-shipping-and-removing-web-platform-API-features), we will only add new APIs to blink that have support from other browser vendors and are properly standardized. This bug just groups a number of related issues tracking our goals for blink. Here is a very rough sketch outlining the sorts of extensions we may want to add
What they are saying is the Chrome team believes it would be better to implement multiple APIs and put the burden on developers to write code for each and every API. This involves a lot of feature detection and of course different code paths for each API. That is the core issue with the touch events API model. With Pointer Events I can write a single code path to deal with a single API. With touch events I must write code for touch, mouse and any other possible input modality. This is extremely problematic.
What Does This Mean For DeepTissue?
What Can You Do?
Join me and complain to the Chrome Team! Leave a comment, white a blog post, check out DeepTissue, HammerJS and HandJS. See what you think. Give me feedback for DeepTissue. I was already making some updates to make it up to date and perform better. I am saddened by the Chrome team's choice to not implement a standard, a standard that has been a W3C recommendation for over a year now.
Is this over yet? I doubt it. So stay tuned, this is a story line with more details and reaction I am sure.