As a member of the Pointer Events Working Group, I am delighted to see that today Pointer Events advanced to an official W3C Recommendation.
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.
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.
- W3C News: Pointer Events is a W3C Recommendation
- MSDN IEBlog: Pointer Events W3C Recommendation, Interoperable Touch, and Removing the Dreaded 300ms Tap Delay
- jQuery Blog: Getting on Point
- Microsoft Open Technologies blog: Pointer Events is now a W3C Standard
- Patrick H. Lauke: Getting Touchy: An introduction to touch and pointer events (workshop slides)