Pointing the Way Forward

Pointing at things on the web used to be simple. You had a mouse, you moved it around, sometimes you pushed buttons, and that was it. Everything that wasn’t a mouse was emulated as one, and developers knew exactly what to count on.

Simple doesn’t necessarily mean good, though. Over time, it became increasingly important that not everything was (or pretended to be) a mouse: you could have pressure-sensitive and tilt-aware pens, for amazing creative freedom; you could use your fingers, so all you needed was the device and your hand; and hey, why not use more than one finger while you’re at it?

We’ve had touch events for a while to help us with that, but they’re an entirely separate API specifically for touch, forcing you to code two separate event models if you want to support both mouse and touch. Chrome 55 ships with a newer standard that unifies both models: pointer events.

A single event model

Pointer events unify the pointer input model for the browser, bringing touch, pens, and mice together into a single set of events.

document.addEventListener('pointermove',
  ev => console.log('The pointer moved.'));
foo.addEventListener('pointerover',
  ev => console.log('The pointer is now over foo.'));

Here’s a list of all the available events, which should look pretty familiar if you’re familiar with mouse events:

Note: Pointer events are confusingly unrelated to the pointer-events CSS property. Even worse, the two can be used together! The behaviour of pointer-events (the CSS property) with pointer events (the event model) is no different than with mouse events or touch events, though, so if you’ve used that CSS property before, you know what to expect.

Different input types

You’ll still have to handle the differences between input types, such as whether the concept of hover applies, but you can do so from within the same event handlers. You can tell device types apart with the deviceType property of the PointerEvent interface. For example, if you were coding a side navigation drawer, you could have the following logic on your pointermove event:

switch(ev.deviceType) {
  case 'mouse':
    // Do nothing.
    break;
  case 'finger':
    // Allow drag gesture.
    break;
  case 'pen':
    // Also allow drag gesture.
    break;
  default:
    // Getting an empty string means the browser doesn't know
    // what device type it is. Let's assume mouse and do nothing.
    break;
}

Default actions

Touch-enabled browsers often make special allowances for certain types of input, overriding certain gestures to make the page scroll, zoom, or refresh. With touch events, this happens more or less transparently, with browser actions happening after the touch events, unless cancelled. This leads to some potentially confusing behaviour for the end user, with both browser- and developer-defined actions taking place sequentially, based off of a single input.

With pointer events, whenever a default action like scroll or zoom is triggered, you’ll get a pointercancel event, to let you know that the browser has taken control of the pointer.

document.addEventListener('pointercancel',
  ev => console.log('Go home, the browser is in charge now.'));

Built-in speed: This model allows for better performance by default, compared to touch events, where you would need to use passive event listeners to achieve the same level of responsiveness.

You can stop the browser from taking control with the touch-action CSS property. Setting it to none on an element will disable all browser-defined actions started over that element, but there are a number of other values for finer-grained control, such as pan-x, for allowing the browser to react to movement on the x axis but not the y axis. Chrome 55 supports the following values:

Pointer capture

Ever spent a frustrating hour debugging why you’re not getting a mouseup event, until you realised that it’s because the user is letting go of the button outside your click target? No? Okay, maybe it’s just me, then.

Still, until now there wasn’t a really good way of tackling this problem. Sure, you could set up the mouseup handler on the document, and save some state on your application to keep track of things. That’s not the cleanest solution, though, particularly if you’re building a web component and trying to keep everything nice and isolated.

With pointer events comes a much better solution: you can capture the pointer, so that you’re sure to get that pointerup event (or any other of its elusive friends).

const foo = document.querySelector('#foo');
foo.addEventListener('pointerdown', ev => {
  console.log('Button down, capturing!');
  // Every pointer has an ID, which you can read from the event.
  foo.setPointerCapture(ev.pointerId);
});

foo.addEventListener('pointerup',
  ev => console.log('Button up. Every time!'));

Browser support

At the time of writing, Pointer Events are supported in Internet Explorer 11, Microsoft Edge, Chrome and Opera, and partially supported in Firefox. You can find an up-to-date list at caniuse.com.

You can use the Pointer Events polyfill for filling in the gaps. Alternatively, checking for browser support in runtime is straightforward:

if (window.PointerEvent) {
  // Yay, we can use pointer events!
} else {
  // Back to mouse and touch events, I guess.
}

Pointer events are a fantastic candidate for progressive enhancement: just modify your initialization methods to make the check above, add pointer event handlers in the if block, and move your mouse/touch event handlers to the else block.

So go ahead, give them a spin and let us know what you think!