Getting on Point

Posted on by

We’re excited to announce that the Pointer Events specification has become a W3C Recommendation! As we’ve said before, we love Pointer Events because they support all of the common input devices today – mouse, pen/stylus, and fingers – but they’re also designed in such a way that future devices can easily be added, and existing code will automatically support the new device. While reaching Recommendation status is a monumental moment, there’s still much work to do.

Pointer Events aren’t a viable solution until they’re usable in all of the browsers that developers are supporting. While that day may seem far away, the jQuery Foundation is dedicated to getting usable Pointer Events in every developer’s hands as soon as possible. We’re working on PEP, our Pointer Events polyfill that Google transferred from the Polymer project to the jQuery Foundation. PEP will be integrated into projects such as jQuery UI, jQuery Mobile, and Dojo. We’re hoping to get out our first release in the next few weeks. If you’re interested in helping out, let us know.

Microsoft is already shipping a full implementation of Pointer Events in IE11 and they had a mostly complete, prefixed implementation in IE10. Mozilla also has a full implementation for Firefox on Windows Metro, though it’s not currently enabled. Both implementation are passing 100% of the W3C Pointer Events test suite. You can follow Mozilla’s progress for all of their supported platforms on https://wiki.mozilla.org/Gecko/Touch.

Of course, the world ain’t all sunshine and rainbows. There’s still no sign that Apple will ever implement Pointer Events. Because of this, Google has decided not to ship Pointer Events in Blink, but rather to try to extend Touch Events to have the power of Pointer Events. The work to extend Touch Events is happening in the Touch Events Community Group to ensure interoperability and standardization. However, there is reasonable concern that adding several extensions to Touch Events will just result in an even more fragmented landscape, eventually worsening the situation rather than improving it. It’s not clear that Apple would implement all of these features anyway, and adding support for hover would require awkward APIs due to the logic that already exists in Touch Events. Even if the power of Pointer Events were added to Touch Events, the awkward event interface isn’t nearly as nice or easy to transition to from Mouse Events.

Despite Google’s current position, they’re willing to continually re-evaluate if shipping Pointer Events will help move the web forward. We’re hopeful that Google will reverse their decision in the future and Apple will eventually be compelled to implement Pointer Events once Safari is the only major browser without support. The Chromium issue for implementing Pointer Events is already in the the 99th percentile of all issues (open and closed) based on number of stars.

As a community, we can shape the future of the web right now. We need to stop letting Apple stifle the work of browser vendors and standards bodies. Too many times, we’ve seen browser vendors with the best intentions fall victim to Apple’s reluctance to work with standards bodies and WebKit’s dominance on mobile devices. We cannot let this continue to happen. The jQuery Foundation is dedicated to driving standards, like Pointer Events, to improve the developer experience and in turn, make the web a better, more accessible place for everyone. Together, we can push the web forward and let standards and better APIs win. We can choose Pointer Events over Touch Events. And we can do it right now, with PEP.

8 thoughts on “Getting on Point”

  2. Jeremy on said:

    Thanks JQuery team! I look forward to working with PEP. I mean, I’m going to need a library to handle mixed touch/mouse/pen events properly anyway, it might as well be a polyfill for an API that’s already approved as an official recommendation of the W3C.

    My experience so far is that almost every web app that tries to handle touch events does it wrong and breaks hybrid devices with both mouse and touch. And every library I’ve seen use Pointer Events or a polyfill has done it perfectly. Case in point – see BabylonJS, which incidentally is perfectly capable of maintaining a simple 60fps WebGL scene on my old nexus 4, on chrome-android, with a polyfill. So, I’m not sure where their performance argument is coming from, and frankly I’m baffled at Google’s decision not to implement this.

  3. Drew M on said:

    This is the latest in a long pattern of Apple going out of its way to not adopt community standards. I’d understand if their alternatives were better, but they’re often worse, or simply arbitrary. My favorite example of this is soundcheck: why does it exist? So Apple has a competing standard to support other than replaygain. Why does iTunes use a bad MP3 encoder rather than the open-source LAME? Because it wants you to use the Apple AAC encoder instead. Why doesn’t Safari support Opus, even though its a web standard? Because Apple. Why are iThings the only flash storage devices on the entire planet that don’t show up as drives? Because Apple. It’s completely ridiculous, and what’s more ridiculous is the community’s willingness to bend over backwards to accommodate Apple’s legion of zealous technophobes. Stop creating pointless division at the expense of progress.

  4. Sean Richter on said:

    Web Accessibility includes visually and physically impaired people who benefit greatly from consistency across devices. Apple seemed to care about education and improving lives at some point before iTunes and iPhones. I haven’t heard much of that marketing recently. Just a lot of patent lawsuits, indentured slavery, and general domination.

  5. Ron on said:

    The WebKit team is extremely focused on performance:

    http://www.webkit.org/projects/performance/
    > We have a zero-tolerance policy for performance regressions.

    They looked at Pointer Events and weren’t convinced they could implement them without sacrificing performance.

    This has nothing to do with Apple supposedly being corrupt, this has more to do with the open-source WebKit developers having a policy and sticking to it.

  6. Ted Wood on said:

    @Ron

    Thank you for the references to WebKit’s Performance policy. That makes it very clear why something would not be added to WebKit. While @Drew makes several valid points, one must put things into perspective. For example, if Apple opened up iOS Flash filesystem to average users to muck around it, could you imagine the mess they would have on their hands? The cost of supporting iOS devices would skyrocket after users unintentionally deleted an important file or accidentally moved a directory. Apple has designed iOS devices with a “Microwave” appliance philosophy… the internals are sealed for the users’ own benefit. Sometimes people forget that Apple’s WebKit project kicked off a while new era of web browser innovations that the entire industry and world benefited from. It’s unreasonable to expect them to follow every innovation at the same pace. There’s a lot of balance that needs to be done to maintain a high-quality user experience. Once Pointer Events meets WebKit’s performance requirements, then I fully expect it to be added. Until then, I applaud the WebKit project for not compromising their high standards.