Pointer Events advance to W3C Recommendation

February 24, 2015Development

As a member of the Pointer Events Working Group, I am delighted to see that today Pointer Events advanced to an official W3C Recommendation.

Having spent the last few years actively researching and documenting the often incongruous behaviour (and idiosyncratic “magic” heuristics) of Touch Events implementations across various platforms (see my JavaScript touch/pointer events research notes post), I’ve experienced 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.

Although admittedly Pointer Events are still fairly low-level, compared to more abstract (and input-agnostic) models such as IndieUI: Events, they are a pragmatic step towards allowing developers to more easily create code that adapts to the variety of old and new devices and input modalities. I see Pointer Events clearly aligned with other technologies, such as CSS Media Queries, in service of a modern “responsive web design” approach.

I strongly believe (and community feedback received by the Working Group overwhelmingly seems to support this belief) that Pointer Events provide developers with the best of both worlds: a simple, unified, and most importantly well documented model to handle user interactions in an input-agnostic way (for situations in which a developer does not particularly care which type of input triggered a particular action), while also allowing for input-specific optimisations (for instance, providing users with a different, more appropriate interface depending on whether they’re using a mouse, touchscreen or stylus). The fact that many JavaScript utility libraries and frameworks internally make use of a very similar custom event model for handling touch and mouse interactions is, in my mind, further proof that the approach taken by Pointer Events is conceptually on the right track.

Of course, today’s announcement is marred by is the fact that the Google Chrome team – despite their excellent collaboration and contributions to the specification – have chosen not to implement Pointer Events, due in large part to the fact that Apple – who unfortunately did not engage in this standardisation process – have quite unequivocally stated that they will not include Pointer Events in Safari (for technical, and some cynics might argue, political reasons). Instead, a parallel effort is now under way to extend Touch Events – the model originally invented by Apple – under the aegis of the Touch Events Community Group (and you can follow the ongoing work on the Touch Events errata on GitHub). In the meantime, for developers who do wish to take advantage of Pointer Events, one possible solution is to use Polyfills, such as the excellent PEP (originally created by Google, now maintained by the jQuery Foundation).

From an accessibility standpoint, my only disappointments with the Pointer Events specification is the fact that, despite trying to provide a holistic event handling model for all types of pointing devices, it does not cover keyboards and keyboard-like interfaces (even though, I would argue, these types of interfaces still represent a means by which users can “point” at elements – see some of the discussions in this mailing list thread and some data points from my research into “Faked” event coordinates). This means that developers will still need to “double up” some of their event handling to cover both keyboards and the abstracted “pointer” devices. However, as a compromise, I’m pleased that I at least managed to sneak an explict note about keyboard accessibility in the introduction to the spec – something that I am hoping to also feed into the work on the Touch Events errata.

Further reading

Categories: Development