Live data from Hacker News

IOS browsers have a 300ms click delay - But developers can bypass it

developers.google.com

21–30 of 58 posts

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#21
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.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#22
post #20

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

Yeah, but it's still less annoying than seeing MAC used for Apple's desktop and notebook line.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#23

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

Try http://assanka.net/content/tech/files/2011/08/fastclickdemo....

You may know this already, but running this test on Android ICS (stock browser) and B can't be selected.

edit http://bit.ly/L2JatN Short url for easy mobile typing

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#24

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.

I put an implementation up on github:

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

#27
post #21

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.

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()

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#28
post #20

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

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!

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#29
post #27
post #21

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.

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()

Fantastic tweak! Fast for good clicks, slow for more ambiguous ones.
Post reply on HN