IOS browsers have a 300ms click delay - But developers can bypass it • Hacker News Board

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

#31

Post by Danieru » Fri, Jun 08, 2012, 1:40 PM UTC

fiznool wrote: post #19

mattcg wrote: post #15

Earlier quoted context omitted.

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 (b…

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?

They only support Windows with IE10 as he said above?

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

#32

Post by ltcoleman » Fri, Jun 08, 2012, 1:45 PM UTC

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.

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

#33

Post by sil3ntmac » Fri, Jun 08, 2012, 2:31 PM UTC

I like cubiq's solution:

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.

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

#34

Post by pasbesoin » Fri, Jun 08, 2012, 2:34 PM UTC

wgx wrote: 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.

My father has minor tremors. I wonder to what extent the feature purposefully -- or inadvertently -- assists such people.

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

#35

Post by danielschwartz » Fri, Jun 08, 2012, 2:39 PM UTC

I actually built something similar to this for where I work. We just recently open sourced it: http://jetsetter.github.com/MobileSafariQuickTap/

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

#36

Post by mrsteveman1 » Fri, Jun 08, 2012, 3:32 PM UTC

huxley wrote: post #22

Void_ wrote: 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.

Mainstream Apple Computer. MAC.

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

#37

Post by gdubs » Fri, Jun 08, 2012, 4:18 PM UTC

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.

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

#38

Post by ferongr » Fri, Jun 08, 2012, 4:20 PM UTC

micheljansen wrote: post #12

Thomaschaaf wrote: post #6

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

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

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.

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

#39

Post by dwc » Fri, Jun 08, 2012, 4:59 PM UTC

wgx wrote: 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.

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.

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

#40

Post by malyk » Fri, Jun 08, 2012, 5:03 PM UTC

wgx wrote: 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.

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.