From the article:

' ... mobile browsers will wait approximately 300ms from the time that you tap the button to fire the click event. The reason for this is that the browser is waiting to see if you are actually performing a double tap. For most buttons we are developing we know that there is no double click behavior that we want to handle, so waiting this long to start acting on the click is time wasted for users. '

The article goes on to discuss how to mitigate against this problem. jQuery Mobile's solution is to use virtual events to listen for touch events rather than mouse clicks. Try listening for vmouseup instead of vclick, this could solve the issue. See http://jquerymobile.com/demos/1.0.1/docs/pages/page-scriptin... for more details.

The delay seems to occur somewhere between the pagebeforeshow and pageshow events- so by that point the click action is definitely already registered. But there must be some function call that slows the whole thing down, interestingly, it doesn't on the iPhone simulator, so presumably it's relatively CPU intensive.

Let me know if you find a fix!

One instance, for example, was in having "fixed" header/footer on the web-app. The rendition of fixed elements would fade-out and fade-in again once user stopped scrolling. This really felt naive and I decided to do that part myself instead.

Obviously, now the situation has improved that we have property 'fixed' acknowledged on the iPad Safari. Will give 1.1 a look again, thanks to this heads-up!

http://cubiq.org/iscroll-4

And, as you say, use the 'fixed' CSS in newer Safari versions that support it.

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

And there obviously is improvement over the previous version, in that, earlier there was some flickering of fixed elements on desktop view-port.

I stand corrected, and appreciate the effort jQuery team.

http://jquerymobile.com/demos/1.0.1/docs/pages/page-links.ht...