The story of pointer events and its API is a complicated and divisive one, but now that it is effectively a W3C standard browser makers should start to support it. The problem is that Apple won't and Google probably won't unless Apple changes its mind. 

We have been following the story of touch events versus pointer events for some time, but it was a reasonable assumption that once a standard was established browser makers would accept the decision. This is important because the Pointer Events API is an attempt to create a common interface for point-oriented input, independent of whether it was generated by touch, a mouse or something more exotic. 

At the start of the process, W3C attempted to use Apple's Touch Event API as a standard. However, without the involvment of Apple the project fell apart because Apple holds patents on the technology and refuses to grant a free use for the specification.

This is where Microsoft came into the picture.  The IE team had been working on its own input API and offered it, the Pointer Events API, as an alternative to Apple's to the W3C. 

At this stage things seemed to be turning out well. The Pointer API is more general and can handle all of the different input devices you might encounter under a single interface. 

Mozilla and Microsoft implemented Pointer Events in their latest browsers and Microsoft has even donated its code to the WebKit project. Apple, however, hasn't enabled the code and shows no interest in supporting Pointer Events. Google at first said that it would support Pointer Events but then decided that it wouldn't. The rationale was partly a question of efficiency, a small problem with coupling touch and scroll events and more importantly the argument that, because Apple wasn't going to support it, the API had no hope of being used in place of Touch Events. 

That is, Google argued that a Pointer API without Apple was not one that programmers would use because doing so would cut the iOS market out from any such web app. Many developers pointed out that if Google had thrown its weight behind the Pointer API that would leave Apple out in the code and might force it to adopt the alternative API. Notice that as Microsoft has contributed the code to WebKit, there is actually nothing much for Apple or Google to do to implement the API. 

Whatever the merits of the Pointer API, it isn't right or good that Apple can exert so much pressure on standards. 

The final twist is that Google is trying to extend the Touch API to include features that make it as flexible as the Pointer API. So not only is it not supporting the standard, it is fragmenting what we already have. 

What do we do?

The practical solution is the all-too-common resort to a polyfill. The jQuery team is working on the Pointer Events Polyfill PEP and hopes for a release in the next few weeks. It should provide a way of using Pointer Events even on Safari and Chrome. The only question is - will it be fast enough?

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info