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.
IOS browsers have a 300ms click delay - But developers can bypass it
21–30 of 58 posts
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#22Am 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
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#23Is there a JS fiddle somewhere where you can see the difference?
Try http://assanka.net/content/tech/files/2011/08/fastclickdemo....
edit http://bit.ly/L2JatN Short url for easy mobile typing
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#24This 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.
https://github.com/alexblack/google-fastbutton
It works crossbrowser (e.g. doesn't break) and has a few tweaks including a hook for jQuery and xui.js
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#25Re: IOS browsers have a 300ms click delay - But developers can bypass it
#26Re: IOS browsers have a 300ms click delay - But developers can bypass it
#27Article 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.
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()Re: IOS browsers have a 300ms click delay - But developers can bypass it
#28Am 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
Re: IOS browsers have a 300ms click delay - But developers can bypass it
#29Article 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()