IOS browsers have a 300ms click delay - But developers can bypass it
developers.google.com
developers.google.com
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.
What I would say is that my mobile apps have very large buttons. Any 'miss' could only really occur at the edge of each button.
So in that case I could use the event coordinates in contrast to the dimensions of the button to decide whether to revert to onClick() behaviour.
Edges ==> onClick()
Center/Sweetspot ==> onTouchStart()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 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...
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.
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.
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.
It also works in Chrome Beta for Android.
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.
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?
The HTML5 Mobile Boilerplate project uses "Fast Buttons": https://github.com/h5bp/mobile-boilerplate/wiki/JavaScript-H...
I don't mind a little typo, but IOS [1] is a completely different operating system...
So terrible title, useful article.
ex http://stackoverflow.com/questions/7375575/android-webview-v...
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.
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.
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'm pretty sure onmousedown fires before click/doubleclick and would dodge the 300ms delay.
edit http://bit.ly/L2JatN Short url for easy mobile typing
On the stock Gingerbread browser though, both Layers do not respond to taps at all.
Why does the submission title say “iOS browsers”?
"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."
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.
I say this as an Android user.