I created a jQuery plugin called fastClick that does this a while back: http://dave1010.github.com/jquery-fast-click/
IOS browsers have a 300ms click delay - But developers can bypass it
41–50 of 58 posts
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#42I created a jQuery plugin called fastClick that does this a while back: http://dave1010.github.com/jquery-fast-click/
I've used this plugin on a number of webapps. Works great! Very simple to integrate into my Backbone.js apps.
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#43Article 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.
Good point. 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()
Great idea!
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#44Am 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
Oops, looks like HN capitalizes the first letter. I always use iOS ;)
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#45The article talks about “mobile browsers”. Neither iOS, Safari or even WebKit are mentioned.
Why does the submission title say “iOS browsers”?
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#46The article talks about “mobile browsers”. Neither iOS, Safari or even WebKit are mentioned. Why does the submission title say “iOS browsers”?
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."
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#47Instead 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.
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#48I 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.
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#49Article 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...
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#50Article 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…
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.