Article asserts it's there to detect double taps, but I'd add that it's a very useful user experience tweak to help deal with mis-taps.

On HN, for example, I'll frequently hit the article link instead of the comments and this delay (combined with the network latency) often lets me re-tap the right link.

This is a known problem, but it's surprising how often it is overlooked. I personally use FastClick.js for this (http://assanka.net/content/tech/2011/08/26/fastclick-native-...), from the guys who did the Financial Times app.

You can see a demo here: http://assanka.net/content/tech/files/2011/08/fastclickdemo....

Of course, that only works if you are on an iOS device.

This article was from 2011 (EDIT: oops, I said 2010 but the article says "January 2011" - though I'm sure they had it out before then) - I think everyone who's done iphone web dev is either using this, or has come up with something similar.

The HTML5 Mobile Boilerplate project uses "Fast Buttons": https://github.com/h5bp/mobile-boilerplate/wiki/JavaScript-H...

Am I the only one who can't stand when people use IOS instead of iOS?

I don't mind a little typo, but IOS [1] is a completely different operating system...

[1] http://en.wikipedia.org/wiki/Cisco_IOS

This is already well known, and the case with most browsers on touch devices.

So terrible title, useful article.

This makes sense for mobile templates where zooming isn't necessary. On sites that retain a desktop style on mobile devices (nytimes), double tapping is extremely valuable to zoom in on particular columns. Hopefully developers don't overuse/misuse this, as it would effectively break that behavior.

For the project I'm working on, whenever I would bind to a 'click' event (via jQuery.on or a Backbone event hash), I instead just pass in a variable that's set to either 'click' or 'touchend' based on touch support detection done on pageload.

If the element is within a scrollable area there's a little bit of extra logic needed to get everything to work happily (so it doesn't fire the event handler if you stop scrolling with your finger on the element). In that circumstance you'd probably better off grabbing one of the many libraries people have written to take care of this, but if that's not a concern (and it isn't in my case, since the parts of the app that shouldn't have the 300ms delay don't scroll), the advantage of this is that the only logic it requires is the touch detection code.

I created a jQuery plugin called fastClick that does this a while back: http://dave1010.github.com/jquery-fast-click/

I think any solution needs to check that only one finger was touched - some solutions forget this check. An iOS quirk to be careful of is that the event.touched array count for a touch event on an element is different if there is also a touch event registered on document (spooky interaction, but true).

Also I would check no modifier key (ctrl,alt,shift,meta) is down to handle mixed keyboard/touch devices. This check is often missed for mouse events, and causes various UI faults in pages.

undefined

Googles fast button is too hard to implement imho. I use jquery tappable for that: http://aanandprasad.com/articles/jquery-tappable/ Provides a great and easy interface + fallback for click input.

A lot more resources on touch/tap events here https://github.com/bebraw/jswiki/wiki/Touch

I like cubiq's solution:

http://cubiq.org/remove-onclick-delay-on-webkit-for-iphone

It uses event capturing so you can bind the listener to an outer div containing many buttons, rather than each button individually.

I heard about this a looooong time ago from Scott Jehl at jQuery con in San Fran. jQuery mobile has known about this for a while. I am glad to see everybody seems to know about it cause I could definitely see devs getting frustrated over this.

I actually built something similar to this for where I work. We just recently open sourced it: http://jetsetter.github.com/MobileSafariQuickTap/

Instead of all that complicated workaround, how about just onmousedown instead of onclick.

I'm pretty sure onmousedown fires before click/doubleclick and would dodge the 300ms delay.

Also, avoid doing as much work as you can inside event handlers.

I guess the tap-event in jQuery Mobile is based on this or am I wrong?

Is there a JS fiddle somewhere where you can see the difference?

Or, how native development still beats "web apps".

The article talks about “mobile browsers”. Neither iOS, Safari or even WebKit are mentioned.

Why does the submission title say “iOS browsers”?

Users told us they would rather have tactile buttons as on a PC keyboard or Blackberry. We're working on a small "smartphone keyboard" for fast "two thumbs" typing like on a Blackberry. The user can plug it into the smartphone when the user wants to type quickly and detach it when they are done and want to store the device.