Last week Luke Wroblewski published an important article in which he said that web developers practising responsive design rely too much on a device’s screen size to determine which device it is.
Last week I got annoyed at the large differences in syntax for vendor-prefixed device-pixel-ratio media queries. I said, half in desperation and half as a threat, that it might be better to have only the WebKit rendering engine and ditch the rest.
Meanwhile I’ve had some time to think about it, and I find that I still support the idea of multiple rendering engines. Competition is still good, just as it was ten years ago.
HOWEVER. There’s an important exception.
W3C unveils the Touch Events Specification. It’s a rough draft, I guess — it doesn’t even have an official URL on www.w3.org yet. But I like it a lot.
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.
It turns out to be possible to handle the touchmove and touchend events with data obtained
from the touchstart event object. It is not necessary to access the touchmove and touchend event
objects, as long as you continue to have access to the touchstart one.
Apparently, the touchstart event object persists in browser memory even when the event has long
ended. More importantly, it continues to be updated with information about the current touch action.
This is interesting. It’s also profoundly different from the desktop, where a similar
trick with the mousedown, mousemove, and mouseup events definitely does not work.
Both iPhone and Android display this behaviour. Therefore future implementations of the
touch events should, too.
Update: I’ve been given to understand that this behaviour will disappear from WebKit. So don’t build your scripts with this behaviour; they’ll misfire sooner or later.
Over the past few weeks I have done some fundamental research into the touch action and
its consequences, and it’s time to present my conclusions in the form of the
inevitable compatibility table. I have also written an
advisory paper that details what browser vendors must do in order to
get by in the mobile touchscreen space. Finally, I discuss a few aspects of my research in this article.
Disclosure: This research was ordered and paid for by Vodafone. Nokia, Microsoft, Palm, and RIM
have helped it along by donating devices to me.
When a user touches the screen of a touchscreen phone, sufficient events should fire
so that web developers know what’s going on and can decide what actions to
take. Unfortunately most mobile browsers, especially Opera and Firefox, are severely
The touch action is way overloaded, and most browsers
have trouble distinguishing between a click action
and a scroll action. Properly making this distinction is the only way of creating a truly
captivating mobile touchscreen browsing experience.
The iPhone’s touch event model is excellent and should be copied by all
other browsers. In fact, these events are so important that I feel that any browser that does
not support them by the end of 2010 is out of the mobile browser arms race.
one problem with the iPhone model, and it’s relatively easy to fix.
I have created a drag-and-drop script that works on iPhone and Android
as well as the desktop browsers,
a multitouch drag-and-drop script that works only on
the iPhone, and a scrolling layer script that
forms the basis of faking
position: fixed on iPhone and Android, who do not
support that declaration natively.
I will hold a presentation on my research at the DIBI conference, Newcastle upon Tyne, 28th April. It will likely
include future discoveries and thoughts.