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.
Seriously, you are claiming that network latency and a delayed response to click events is a GOOD thing because it lets you fix mistakes that you made? Sorry, that is not how you design a product/feature.
The problem you are mentioning has also been solved by Google. In Ice Cream Sandwich when you click on a link that is close together with others, it will magnify the area to make it very clear which link you want to click. This is a solution to your mis-clicks - not a latency delay on every click so that you can fix it if you clicked wrong...
In the absence of zoom-on-ambiguous, why is it so bad? I certainly have trouble accurately clicking links on a phone, so having no click correction is certainly worse than artificial latency.
Don't confirmation dialogue boxes and password confirmation fields fall into the same category? They assume imperfect user input, and their mechanisms for avoiding errors slow the user down.
What's right for web sites (300ms delay) need not be what's right for web apps (0ms delay). I think it's a smart default, and devs making usability tradeoffs can decide when to remove it.
From the article: "...since we wanted users to be able to dial phone numbers rapidly."
I think there are specific cases where eliminating the delay is appropriate. The very real concern is that developers will use this with abandon. There are many sites where it's easy to mistap, and the delay behavior serves its purpose well. Developers should think twice before breaking whole-platform conventions. Whatever they might personally think is "the right way," breaking with conventions almost always surprises and frustrates users.
The other reason it's there is to detect scrolling instead of simply touching. If you don't move your finger in those 300ms then it's a tap, if you do then it's a scroll. This tweak breaks that.
The delay is there to allow you lift your finger and see the link turned gray (or whatever the selection color is). This feedback is crucial even in cases where you tapped on the right thing--how else would you know you got the right thing?
There are valid reasons to override this, but developers and designers should be sure that their tap targets are huge when they do. Otherwise they're depriving users of a pretty important piece of feedback.
Unfortunately I'd blame this down to this site's poor user experience on iOS. The 300ms delay is thee to support all cases of user gestures, not be a crutch for poorly-designed sites.
One of the developers of FastClick.js here. We made this thing because we thought that the problem deserved a thin compatibility layer as a solution, rather than forcing developers to rewrite their code to use a different kind of button all over the place (then rewriting it again when the devices change their behaviour).
The code is in production use on the FT web app, which is deployed across iOS devices, Android (both Chrome and the Android browser), Firefox (in test), Blackberry (both Playbook and phone) and Windows (IE10). We've fixed a bunch of bugs since the initial release and we should be putting the new code on GitHub in a few days (http://github.com/ftlabs).
Feel free to post questions about FastClick on Stackoverflow if you have any problems... I'm monitoring it for mentions of FastClick and will answer most of the time.
Great library, going to give it a shot in one of my upcoming projects.
Quick question - I just tried the demo on IE on a Nokia Lumia 710 running WP 7.5 Mango, and there was no difference between A and B. Do you have any idea why FastClick might not work on Mango?
Excellent, I did not test that yet. I mostly meant to say that you cannot see the delay if you are browsing on a non-touch device (because there is no delay).
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.
In this case it's because HN capitalizes the first letter of story titles. There should really be some hardcoded exceptions; it's surprising how often titles begin with iPhone, iOS, or jQuery!
Because the title is "IOS browsers have a 300ms click delay", when in fact it affects a lot of mobile platforms (BB, iOS, WP7, some older Android versions), not just iOS. The article itself doesn't even mention iOS or iPhone.
Note that Google doesn't mention iOS or Apple anywhere in the article, yet the submission is "iOS has a 300 ms delay". It's in Android webview, too, not just iOS (probably it's something in WebKit?)
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 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.
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.
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.
FWIW this is broken on Opera Mobile Android. Tapping Layer B once results in it switching to green and then back to white, like it was tapped twice. Layer A works as expected, with a slight delay.
On the stock Gingerbread browser though, both Layers do not respond to taps at all.
Probably because it's mostly fixed in Android ICS, as is slyly stated at the very end of the article:
"We hope that browser developers will solve this problem in future releases by firing click events immediately when zooming is disabled on the website (using the viewport meta tag). In fact, this is already the case with the Gingerbread Android Browser."
Is it really fixed in ICS? Last time I tried my test case with my ICS phone it was still happening. Further, the iPhone wasn't exhibiting the ghost click behavior.
I really wish Google would make the Android browser blow mobile Safari out of the water. It'd be good for their business. As someone who used to do mobile web development full time, Android felt like IE 6/7 half the time.
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.
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.