Do we need touch events?

One reaction I received about my touch research was: Do we really need the touch events? Can’t we just fire the mouse events when a touch action occurs? After all, touch and mouse events aren’t that different.

That’s a fair question. It deserves a fair answer.

The problem

Right now, iPhone and Android support the touchstart, touchmove, and touchend events. Let’s say my advice is accepted and future browsers also support the touchenter, touchleave, and touchhold events.

The point here is that this series of events isn’t that different from the mouse events. Respectively, mousedown, mousemove, mouseup, mouseover, and mouseout fulfill the same role as the first five touch events. The touchhold event does not have a direct mouse equivalent, but it basically fulfills the same function as a right-click detection script.

So if mousedown is really the same as touchstart, why bother with new events? Can’t we just write a mousedown script that is triggered when the user depresses his mouse button OR touches the screen?

The issues

As far as I can see there are three fundamental issues involved:

Touch interaction is different from mouse interaction. Not hugely different, but different enough to warrant separate events. It MUST be possible to write ONE single JavaScript file that works optimally in any circumstances, on the desktop, in a mobile browser, or in a widget manager, with the user using the touchscreen, the mouse, or the keyboard, as he sees fit. That implies the web developer MUST be able to distinguish between mouse-driven and touch-driven interaction. The mouse events have already been implemented as legacy events in all touchscreen browsers. They all fire after the user releases the screen.

Let’s study these issues a bit further.

Issue 1: difference

Although at first sight it seems as it touchstart is equal to mousedown, touchmove to mousemove, and touchend to mouseup, this is not really the case.

Take a look at my second scrolling layer script. It was written for touchscreen phones, and works perfectly if the browser supports the touch events. Currently only iPhone and Android do.

I added the mousedown event to touchdown, mousemove to touchmove, and mouseup to touchup. Try it in a normal desktop browser. You’ll find that, although the script works, the interaction just doesn’t make sense. The mouse events aren’t quite the same as the touch events, even though they’re pretty similar.

For more fun, try using it with a touchpad.

If you really want to have fun, try the script on a Nokia S60v3 device, which has a pseudo-cursor and implements the mouse events exactly like desktop browsers. The script works ... in a way.

Question to UX experts: how should the scrolling layer work when the user has a mouse?

In other words, we need a different interaction model for desktop browsers. That requires us to first make a distinction between mouse-driven and touch-driven browsers. But how?

Issue 2: one file

There’s one extra requirement: I absolutely want to be able to deliver one single JavaScript file that contains all the scripts necessary for all interactions. And obviously I do not want to use a browser detect at all in order to determine whether a certain browser needs the mouse or the touch version.

So how do we distinguish between the two? Simple: see if a touchstart event fires. If it does, the browser is certain to be a touchscreen device and we should disable the mouse events.

It would work something like this:

var testEl = [the element you want to do something with]; testEl.onmousedown = function () { // initialize mouse interface } testEl.ontouchstart = function () { testEl.onmousedown = null; // initialize touch interface }

This works fine. The touchstart event fires before the mousedown event, and therefore we can wipe the mousedown event handler before it’s ever executed.

A really proper script would have a third interaction model for using the keyboard. I haven’t written that yet because it’s somewhat more tricky than the touch/mouse one. I will have to deal with S60v3, where the “arrow” keys guide a pseudo mouse cursor across the screen and both the mouse and the key events fire. Besides, the user may alternate between the keyboard and either a mouse or a touchscreen.

Still, we can use a similar trick here: we know that the user is using a mouse if the mousemove event is detected. More specifically, if two mousemove events are detected within a short period of time. After all, all mobile touchscreen browsers will fire one (and only one) mousemove event when the user releases the screen, and that does not constitute evidence for a mouse-based interface.

Of course we can only distinguish them if keyboard use fires different events than mouse use. As we know it does: the keydown, keypress, and keyup events have long been supported by all browsers. Imagine a browser in which depressing a key would fire a mousedown event!

This sort of distinguishing between different interaction models is only possible if the three models use different events. If the touch actions would also use the mouse events, it would be impossible to distinguish between the two.

Issue 3: prior art

Finally, let’s repeat it once more, all touchscreen browsers (with the sole exception of the two Vodafone Widget Managers) already fire all mouse events in one long cascade when the user releases the screen.

We shouldn’t require all browsers to change this behaviour. First of all it doesn’t make sense, and secondly they won’t all do it, leaving us stuck with an impossible situation where some browsers support the mouse events as if they’re a desktop browser, and others as if they’re a touch browser. That’s a recipe for disaster.

Separate touch events

So I strongly believe that all mobile touchscreen browsers MUST (in the sense of RFC 2119) support separate touchstart, touchmove, and touchend events and relegate the mouse events to legacy status.

Web developers will benefit from this since they can easily distinguish between the various interaction modes and create scripts that are suited to every one of them.

Comments are closed.