Chrome will stick with Apple's Touch Events over Microsoft's Pointer Events.

Developers on the Blink browser engine, the core component that powers both Google's Chrome browser and Opera, announced Friday that they're dropping support for the Pointer Events specification originally devised by Microsoft.

There are two competing specifications for handling touch input in the browser. The first, Touch Events, was devised by Apple and integrated into WebKit. While Touch Events was part of the World Wide Web Consortium's (W3C) standards track, for a long period they were held up in patent limbo, with Apple claiming that it owned patents that covered the specification and refusing to offer a royalty-free license for those patents. During this period of uncertainty, W3C stopped work on Touch Events.

In response to this, Microsoft devised a similar but different specification, which it called Pointer Events. Pointer Events both avoided Apple's patent claims, and offered some features not found in Touch Events. In particular, Pointer Events allowed Web content to handle mouse, touch, and stylus input in a more or less uniform way. With Pointer Events, developers can specialize these input methods where necessary, but also handle common behavior with common code.

Since the work on Pointer Events started, the patent issues surrounding Touch Events have been largely resolved, with W3C deciding that Apple's patents were irrelevant and as such no license was necessary. Even with this work resuming, Microsoft, Google, and Mozilla all worked to implement Pointer Events in their browsers. Google's Blink engine, being derived from WebKit, already includes Touch Events.

But Google has announced that this work is stopping. The company's developers gave three reasons for the change. The first is that Mobile Safari only supports Touch Events, making it difficult for Pointer Events to ever gain traction, much less win out. Second, the way Pointer Events worked caused performance issues for WebKit and Blink not found in Touch Events. Third, Pointer Events precluded implementing some common design concepts such as pull-to-refresh.

Mozilla's work on Pointer Events seems so far to be continuing.

In announcing the cessation of support, Google noted that it had enjoyed a good working relationship with Microsoft on the technology, which the company hopes may continue in the future.

Google's new plan is to extend Touch Events in such a way as to do what Pointer Events offered. The desire among developers to be able to handle different input methods in a common way persists, and this desire is only likely to grow stronger in the future. Microsoft, of course, has been the strongest proponent of devices that include any combination of stylus, mouse, and touch input, but Google too has done work in this direction, both with touch-enabled ChromeOS machines, and mouse/trackpad-enabled Android machines.

These devices continue to be a challenge for Touch Events. Many Web applications assume that Touch Events are mutually exclusive with Mouse Events, with the result that they don't work correctly on mixed-input hardware. And even when apps do handle mixed-input hardware correctly, supporting both Touch Events and Mouse Events simultaneously tends to require a lot of code; much more than Pointer Events. One factor influencing the implementation of Pointer Events in Blink in the first place were demands from real developers to support them, precisely because of the unification and simplicity they offered.

Google is not the only company to notice the dominance of Touch Events, troublesome as they may be. Windows Phone 8.1 includes Internet Explorer 11, and while this is for the most part identical to its desktop version, one notable difference is that the phone version includes Touch Event support. This is one of the concessions Microsoft has made to Mobile Safari's Internet Explorer 6-like position on the mobile Web. Due to the problems with mixed input devices, the desktop browser omits Touch Events support.

Google's first point, however, is a little surprising. Google's platform has overtaken Apple's, which ought to give the company some ability to push for non-Touch Event technology. Apple's lack of support (and refusal to participate in any W3C group working on input standards) remains a substantial impediment, but it's an impediment that should decline with time. As such, it's not immediately obvious that the widespread use of Touch Events is some immutable fact of life.

At one time, Internet Explorer 6 was even more dominant than Mobile Safari now is, and implemented fundamental CSS features in a manner that was did not conform with specifications at all. Mozilla stuck to its guns with the fledgling Firefox browser, following the specification rather than trying to fit with the majority browser. While it didn't happen overnight, developers did do the work required to support the new browser. Pointer Events may face an uphill battle, but their cause does not seem quite as impossible as Google has suggested.