Last week, I published the first draft (and subsequent updates) of the Web Interface specification, which defines touch events. This is the first spec from the new W3C Web Events Working Group.

Peter-Paul Koch (PPK) gave it a positive initial review. Apparently, others thought it was news-worthy as well, because there were a few nice write-ups in various tech sites. Naturally, cnet’s Shank scooped it first (he has his ear to the ground), and it was fairly quickly picked up by macgasm, electronista, and Wired webmonkey.

I thought I’d go into a few of the high-level technical details and future plans for those who are interested.

Touch interfaces are nothing novel, nor is using them with Web content, but there are enough differences from mouse interaction that specifying them should lead to easier development and better user experiences on the Open Web platform (or in HTML5 webapps, if you prefer that buzzword).

The most important thing to note for multi-touch events (using more than one finger, say) is that you want the different touch-points to be considered together, not as completely unrelated events. The WebKit implementation, used in the iPhone and Droid smartphones, as well as many, many others, used a good model for this, with each event exposing lists of currently-active individual touch-points; with wide deployment of WebKit already, it was an obvious starting point. PPK’s blog post was off on one minor detail here: while I did base the spec on WebKit’s behavior, I didn’t base it directly off of Apple’s documentation; I wrote it from scratch, for better or worse, and extended it for broader applicability.

One of these extensions was to take PPK’s suggestion to add ‘touchenter’ and ‘touchleave’ events, the equivalent of the ‘mouseenter’ and ‘mouseleave’ events that we finally specified in DOM3 Events, which work much more intuitively than ‘mouseover’ and ‘mouseout’.

I also extended the WebKit model to add ‘radiusX’ and ‘radiusY’ attributes, to indicate the general size and shape of the thing that touched the surface… say, a fingertip or a stylus (a fancy way of saying “pen-like stick”), described as an ellipse. I’ve been soliciting use cases and requirements for a couple of years, and this is meant to cover a similar request across different devices.

That leads me to mention the other use case for this specification: pen-tablets. Almost a decade ago, I was writing a browser-based SVG editor called SVG-Whiz (long since decomposed into digital fertilizer), and I wanted to be able to use my Wacom tablet with it. It worked okay as a mouse replacement, but I had to choose the stroke-width manually… I couldn’t use the tablet’s built-in pressure sensitivity.

We’re about to change that. Another change to the WebKit model is the addition of a ‘force’ attribute to indicate the level of pressure used on the touch or tablet interface. This will be useful for SVG or Canvas API drawing apps, games, and myriad other purposes. For example, most touch screens don’t have the capability to detect hovering (some capacitive screens being the exception)… this is a challenge for accessibility, but perhaps the pressure sensitivity—expressed in the ‘force’ attribute—could be applied to that end. We may specify a new related CSS mode, or simply define when existing ones apply, such as triggering the CSS ‘:hover’ pseudoclass past a certain pressure threshold (device-specific and user configurable, of course).

(On the subject of new CSS properties, Nokia has made the suggestion of haptic feedback properties for touchscreens, based on their implementation. This could be a very interesting addition to touch interfaces, even if it’s not available on all devices. That work would be handled by the CSS Working Group.)

In addition to pressure-sensitivity, pen input has other characteristics that distinguish it from touch, including the angle of the pen, so we may add that as well. Pen-inputs, either through tablets or stand-alone digital pens, often include particular mode-shifting buttons, so we have added attributes to detect when the alt, shift, and control keys (or buttons) have been pressed.

So, to cover a wide range of devices, we will be defining some capabilities beyond basic touchscreens: multi-touch, touch area, force, perhaps pen-angle, and even haptic feedback. Not every feature will be available for every device, but they will be useful for those that do, but we want the spec to be future-proof and device-independent.

This leads me to another touchy area: gestures. One of the common requests I’ve gotten is to add events for specific gestures, like pinch, swipe, twist, flick, etc. There are two problems with trying to standardize this right now:

1. Each device and each platform has its own gestures, sometimes several to do the same thing, and there is still room for innovation there;
2. It’s a patent minefield.

Instead, we intend to specify higher-level “intentional” events, like zooming in or out, panning, navigating, editing, etc., and define a way to map between the physical actions (touching the screen and moving your fingers) and the intention event (zooming in); it also means we can map between input on other devices, like keyboard and mouse, and the intent behind those actions. An additional aspect of this is another proposal by Nokia, the transform action events; these match the transforms in SVG and CSS, such as translateX and translateY, scale, and rotate, and add the ability to detect the rate of the actions. Having all these high-level events will ultimately make it much easier to author content and applications that work on multiple devices.

And though gestures are different on each device, we do plan to create an informative document detailing some common ones, perhaps something like the excellent Touch Gesture Reference Guide by Luke Wroblewski, Craig Villamor, and Dan Willis. That might eventually lead to some industry consensus about future efforts to define gesture events.

Last but not least, one of the additions I made to the spec after the first draft was to add my co-editors, Sangwhan Moon from Opera and Matt Brubeck from Mozilla, both of whom have already made excellent suggestions we’ve integrated into the spec, and who have volunteered to help me write the spec. It’s a positive sign that we’ve got active participation from so many different browser-engine developers, since interoperability here is the most important thing.

For me, this specification has been about a decade in the making… it’s one of the things I wanted to tackle when I first came to W3C, even before I worked there. So, I’m very excited to finally be doing it, and to help make touchscreens and pen-tablets part of the Open Web platform. With some hard work and a little luck, we could get this spec completed and implemented in browsers by early next year.

So, if you are interested in helping us make sure the Touch Interface spec meets your needs as a user, developer, or implementer… get in touch!