By default, if you tap on a touchscreen it takes about 300ms before a click event fires. It’s possible to remove this delay, but it’s complicated. I investigated it.

continue reading

Returning false, or calling preventDefault(), in an event handler is supposed to prevent the default action of the event. So if a user clicks a link the link is not followed, if the user scrolls nothing actually happens, etc. Does this work everywhere for the touch events? My latest research gives the details.

continue reading

From Friday until today I spent far too much time reverse-engineering iOS behaviour I was already supposed to be aware of. However, I also found a twist that hasn’t been documented so far — I think.

The behaviour I should already have known about was that during the touch event cascade, Safari iOS stops firing events when a DOM change takes place. The twist is that only DOM methods such as appendChild() count — but innerHTML does not.

Many thanks to Patrick Lauke for helping me out here and putting me on the right track.

continue reading

It’s that time again when I worry about the bubbling of mouse events on Safari iOS. Three years ago I did some research and a follow-up, and I found that the click event refused to bubble up to the body or higher in Safari iOS, unless some specific criteria were met. Today I repeated that research, and found the situation has changed.

continue reading

Just now I published the latest touch action tests. There are no nasty surprises, although IE remains idiosyncratic.

The most common touch action is the single tap. When that action occurs, browsers fire off a whole slew of events, mostly in order to remain backward compatible with older sites that only use mouse events. Although there are quite a few deviations from the “standard” order of these events, they don’t matter much. The average script won’t break because the mouseover event fires before the touchstart event. Still, I documented all deviations. Who knows when this will come in handy?

I also studied the double tap, pinch-zoom, and scroll actions and found that browsers generally fire those events you would expect. The contextmenu event, which could serve as a useful proxy for a touchhold actions, is badly supported.

I also updated the mobile events page with the new information gleaned from these tests.

Enjoy.

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.

continue reading

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.

continue reading

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.

continue reading

Last Tuesday I blogged about event delegation on the iPhone and concluded that the click event, contrary to all others, is not delegated upward unless you also give the element the user clicks on an onclick event handler (which may be empty).

Turns out this is not the whole story.

continue reading

From the dawn of history browsers have supported event delegation. If you click on an element, the event will bubble all the way up to the document in search of event handlers to execute.

It turns out that Safari on the iPhone does not support event delegation for click events, unless the click takes place on a link or input. That’s an annoying bug, but fortunately there’s a workaround available.

continue reading

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.

continue reading

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.

continue reading

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 deficient here.

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. There’s only 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.

continue reading

Yesterday I walked into the local phone store because the “Temporarily Unavailable” sign had been removed from their “Get your iPhone here” poster. To my utter surprise they had six (6!) entire iPhones for sale, and no, there was no waiting list. I walked back home with a shiny new gadget, impatient to start testing it.

Meanwhile I’ve done some tests; now it’s time for a report.

Before we continue, let’s get the bad CSS news out of the way: Safari on the iPhone does not support position: fixed. Certain Other Browsers were ridiculed for this lack; Safari won’t be.

I’ve updated the CSS Table, the Core Table and the Events Table. In this entry I’m going to talk about JavaScript events on the iPhone. They’re — interesting.

continue reading