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.

Maintaining an open source project as big as jQuery requires the use of various software and services. Two of the products we rely on and enjoy the most are GitHub and WordPress.

We’ve been using and loving Git and GitHub for years now. The community collaboration has been phenomenal. We’ve seen a massive uptick in community-provided bug fixes, refactors, new features, etc. Even within the team, the services provided by GitHub have provided a huge productivity boost. Forks and pull requests provide a great mechanism for sharing code and peer code reviews. The interface renders almost every file exactly how we want it to, especially Markdown. The API and service hooks provide a great way to automate various tasks.

Even longer than we’ve been using GitHub, we’ve been using WordPress to manage our various web sites. We have a surprisingly large number of them. Between project sites, API documentation, tutorials, contribution guides, events, and organization sites, the number of web sites we maintain rivals the number of code projects we maintain. WordPress provides tools which make managing this many sites with a common brand almost as simple as maintaining just one site with shared users, theme inheritance, and a great plugin architecture, providing even more hooks than GitHub.

The missing pieces

Unfortunately, our WordPress experience lacked all the collaboration tools and workflow we love. Only a few people had access to edit content, and collaboration without pull requests is painful. Managing content on api.jquery.com was an even bigger hassle because of our XML based workflow, which the WordPress editor clearly wasn’t designed for.

While GitHub has tons of tools that we love, and they even have GitHub Pages, it lacked the infrastructure we need for managing our site content. GitHub Pages have no built-in features and can’t have any server-side processing. Features like search and commenting either need to be added per site via client-side JavaScript or can’t be implemented at all.

Bringing it all together

In order to resolve these issues, we decided to find a way to bring these two products together and get the best of both worlds. It started off pretty bumpy, but we managed to do just that! Things started to really pick up when we got the support of WordPress’ Lead Developer Andrew Nacin. Nacin played a key role in getting our new infrastructure set up and ensuring we were using WordPress as efficiently as possible. With his help, and the help of a few new projects – such as node-wordpress, grunt-wordpress, and grunt-jquery-content – we were able to build exactly what we wanted.

We now manage our WordPress theme in jquery-wp-content, and the content for all of our sites are stored and managed in individual repositories on GitHub. Storing the content of each site on GitHub gives us all the benefits of tracking tasks in issues, discussions on pull requests, visual diffs for changes, etc. The content of each page is generated by grunt-jquery-content from HTML, XML or Markdown source depending on the repository. This content is then synced to WordPress using grunt-wordpress. Just like our code, all of our site content is open source and released under the terms of the MIT license, with the exception of our branding which is not licensed for use by others.

We’re now powering a dozen and a half sites with this new process, averaging 20 contributors per site. Our most popular sites for community contribution are learn.jquery.com which is nearing triple digits and api.jquery.com which currently has 50 contributors. We’re averaging 40 pull requests per site as well, showing just how beneficial this new workflow has been for the team and the community. If you’d like to join in on this community effort, you can read more about our process and how to get involved on our contribution site and help make jQuery better for everyone.

Touch events have become a hot topic for web developers as more and more companies move into the mobile space. Most of us know that touch events support single and multi-touch tracking. Some of us know the trickiness of working with touch and mouse at the same time. Fewer know that there are multiple touch event models, and even fewer have tried to support multiple models at the same time. I’d like to talk about where we are today, how we got here, and the potential problems we may face in the future.

A Brief History

Back in 2007, Apple introduced the iPhone, and with it came touch events. Neil Roberts sums up the Apple implementation well in a SitePen article: “Though at first the APIs seem a little sketchy, once you’ve learned them you should be able to do amazing things in your application.” Sure enough, we’ve seen plenty of amazing things, without too much complaint of the “sketchy” API. This model was later implemented by Android, Nokia, RIM, Opera, and others. Apple’s implementation is still only available in their private fork of WebKit; it wasn’t until the end of 2009 that touch events first appeared in the main WebKit repo, coming from the Android implementation.

Also in 2009, the W3C started discussing a unified pointer model for DOM Level 3 Events. The idea was that touch (including multi-touch), pen/stylus, and mouse events would be coalesced into a single model, making it easy to support all pointer types at once. However, this was abandoned because the goal at the time was to keep the spec as small as possible in order to become a recommendation faster.

Another two years later (March 2011), Mozilla released Firefox 4, featuring their own flavor of touch events. The Mozilla model is much closer to the mouse event model and the abandoned W3C model in that the event objects are flat; properties such as event.pageX exist and there is no touch list. If you want to track multiple touches, you can do so via the event’s streamId. Mozilla later deprecated this implementation in favor of an emerging W3C spec based on Apple’s model.

In January 2011, the W3C started drafting a Touch Events spec based on the WebKit implementation. A few months later, it became a Working Draft, and in December it became a Candidate Recommendation. The next month, a Patent Advisory Group (PAG) was formed in order to investigate patents disclosed by Apple. Apple’s absence from the Touch Events Working Group (WG) and their patent disclosure has caused the W3C to stop work on the spec and they do not plan to continue until the PAG has concluded and/or makes a recommendation to the WG. As of this writing, the PAG has not made a decision about the impact of the patents, but the group’s goal is to reach a speedy conclusion.

Meanwhile, Microsoft took a different approach to touch and has implemented their own pointer events in IE10 with the MSPointerEvent object. The MSPointerEvent object is similar to the original Mozilla implementation, in that the event objects are flat and contain a pointerId property. However, there are some important differences between MSPointer and all of the other models, which are touch-specific.

Note: The above is just a brief history of touch events on the Web; if you’re interested in the history of touch interfaces, you might want to check out Bill Buxton’s Multi-Touch Systems that I Have Known and Loved.

Pointer Events vs. Touch Events

As mentioned above, generic pointer events such as the original W3C idea or MSPointer, have the benefit of supporting multiple pointer devices. In fact, with a Samsung tablet running Windows 8, mouse, pen, and fingers are all normalized to MSPointer; you can even use the pointerType property to determine which type of pointer is being used. In addition to supporting all current pointer devices, MSPointer is designed in such a way that future devices can easily be added, and existing code will automatically support the new device. Even better, MSPointer event objects have the same structure as other events, reducing the learning curve compared to the conglomerate of TouchEvent, TouchList, and Touch.

Another big difference between MSPointer and Touch is that MSPointer has support for hovering (over and out events). While most touch devices have a hardware limitation that doesn’t allow for hovering, Sony recently announced the Xperia sola with “magical floating touch technology.” This brings up an important issue: Touch Events were designed based on a specific device for a specific type of input. Pointer Events represent a completely different approach to input on the Web. While we’ve already covered how this impacts developers, it’s interesting to consider the impact on hardware manufacturers. In order for Apple to succeed with touch interfaces, they had to create a new event model. Innovation for new form factors and new input methods will either be stifled by the existing standards or will require a new set of APIs, following in Apple’s footsteps with the iPhone and Touch Events. Pointer Events provides a clean solution not only for developers, but for hardware manufacturers as well. It’s conceivable that in a few years developers could use Pointer Events as the only event model for pointers, leaving Mouse Events as a thing of the past.

A Splintered Future

Although the W3C is still planning to move forward with the Touch Events spec (pending a recommendation from the PAG), the future is unclear. Even if the PAG determines that Apple’s patents don’t apply and the spec becomes a W3C Recommendation, it’s not clear that Microsoft would implement such a model given the need for a multi-input event system in Windows. If the W3C were to change directions and start a Pointer Events spec, it’s not clear that Apple, or more broadly WebKit, would implement the new event model. It’s entirely possible that even with a W3C Recommendation, we’ll be stuck for years without a consistent event model across browsers and devices.

Regardless of which model the W3C chooses to pursue, jQuery is dedicated to filling in the gaps, just like we do for other events such as submit and change. We think the pointer event model is easier to use and more future-proof, and we hope that it can be standardized, even if Touch Events are standardized as well. However, we are only interested in normalizing to a W3C Recommendation, and will not provide custom pointer events if there is no official W3C specification. We’re working with the W3C and Microsoft to try to find the best way forward for our users and the Open Web.

Call to Action: Microsoft to Submit Pointer Event Proposal

We would like to publicly call upon Microsoft to submit a proposal to the W3C for Pointer Events. The Touch Events Working Group, and by extension various browser vendors, have stated interest in pointer events. The most effective way to proceed would be for Microsoft to officially submit a proposal to the W3C.

Call to Action: Community to Experiment with Both Event Models

We would also encourage the community to experiment with Touch and MSPointer. Play with the APIs, build apps, and provide feedback. If you’re interested in this, but don’t have the necessary hardware, consider pairing up with one or more local developers who do. While there are a lot of developers building on top of Touch, there are very few people building on top of MSPointer, and even fewer publicly comparing them. We encourage you to send your feedback directly to the W3C public-webevents mailing list, but feel free to leave feedback here and we will pass it along.

Call to Action: Submit Prior Art

If you know of any prior art for multi-touch/touch lists, even outside of the Web, please get in touch with the W3C. This includes programming models and APIs, especially those using events. This will help the Patent Advisory Group come to a conclusion sooner. Again, if you’d rather leave comments here, we will pass them along.