This seems useful in a subset of circumstances but should really be used on a limited basis.

A lot of careful design and thought went into existing behavior. The default delay is there for a reason - to better understand user intent and give access to additional features. Users are also used to the delay and may be frustrated or confused rather than delighted at the change, and some touch-hold functionality may be affected.

I'd argue the opposite, native controls on most mobile platforms have a very low delay and almost always respond faster than web interfaces. The delay perpetuates the stereotype of unresponsive web apps on mobile devices.

I agree in part.

This is not something to throw into your average mobilized web page, but into an HTML application designed for mobile. Facebook clearly does something like this for their mobile app.

That's actually what I'm working on (phone gap app) and why I plan on using this.

Use at your own risk. On our website it brought a lot of small unanticipated errors in the user interface that we only uncovered slowly.

It didn't work in IE8 out of the box. Some users reported they had to double tap very fast on iPad to actually activate any link (I couldn't reproduce it on my iPad). On some older Android devices it made links and menus behave erratically.

In the end we disabled FastClick completely.

Given that this library is specifically aimed at mobile browsers, why would you have problems with ie8?

Your other complaints seem inconclusive.

By default, you're wasting 300ms of most peoples time every time they click, this kind of default automatically puts any standard HTML you do on mobile behind native controls.

On android for instance, you should almost never expect your user to double tap as that result is now typically proceed with long presses.

You can load it conditionally for mobile safari only. IE, something like this (using the lightweight head.js loader):

        // load fast click if mobile safari
        if(navigator.userAgent.match(/(iPhone|iPod|iPad)/i) {
          head.js("js/fastclick.min.js", function() {});
        }

or include it in your main compressed js assets but only execute if mobile safari

syntax error, missing ) after the if statement. I always do that too.

I'm sure it won't be too difficult to fix those bugs. What version of FastClick were you using? Were you testing on Android 2? If so I'm working on support for that.

FastClick dev here. We're trying to support as many platforms as possible, so if you notice any problems while testing please file an issue, even if your platform is IE8. I typically fix really bad bugs within about 24 hours. The version on GitHub is the same one that's used by the FT web app, which is built to support Android, Chrome, IE, Firefox, Safari and so on.

Great job!

One of the concerns to use it might be: if the user want's to zoom in, and happens to be double tap on the FastClick enabled button, two separate click events would be triggered instead.

I am wondering if it's possible to use this technique only on UI, but still delay the event handling. A timer can be used to determine whether it's an independent click or a double-tap-to-zoom-in event. In this way, the double-tap is not broken, but UI feels much more responsive.

Nice implementation. For those not wanting to use a library you can achieve the same functionality by binding to the touchStart/touchMove events instead of 'click'.

Do mouse clicks active those events too?

touchend actually, and the fake "click" should be aborted if the user scrolls.

This should be of interest as well:

https://developers.google.com/mobile/articles/fast_buttons

Double clicking makes little sense on mobile as it is, and the delay should be done away with by default.

Thanks for the reference, and thanks to the OP

Why do the mobile devices not implement this by default?

A built in delay is making sure that you actually want to tap, and not swipe or double tap.

So it's safe to say this library might annoy users with accidental clicks.

I guess that depends on how you use it. Probably unwise to use it on every link, but certain UI elements could benefit from it.

Double clicks actually.

I made a jQuery plugin like this a while back [1] but this looks more polished. I'd recommend against using something like this unless you're sure you need it.

[1] https://github.com/dave1010/jquery-fast-click

I wrote a similar library for some mobile web apps I'm working on.

https://github.com/kikinteractive/clickable

It has support for:

* "fast" clicking

* managing downstate in CSS (like :active)

* using the native disabled property

* sticky downstates

The impact this makes on perceived speed is impressive.

However, a word of caution. We tried this for a while and found it interfered with scrolling behaviour on link-heavy pages, not to mention making event capture for swipeable elements difficult.

The technique is a useful one to be aware of, but I'd be wary of using a library for this - it didn't work out for us, and I'll hazard it is unlikely to work as well it initially appears to.

That initial 300ms speedup is astounding, though :)

I recently changed the way touch events are observed - bubbling listeners are used instead of capturing listeners. This fixed a problem we had with scrolling libraries. Have you tried the latest version?

It also conflicts with tap/click markers, when initiating animations on click event.

Will you file an issue with a reduced test case please?

It's specific to the iPad. The marker indicating a tap, will show on specific UI elements, since everything is shifting due to the animation. The case is from Google's implementation, not this one.

Not really something we can do anything about - it's an edge case.

Other methods mentioned in the thread such as Google's fast button or binding touchstart/touchend don't handle everything this does, such as input fields/checkboxes. This works also well with responsive AngularJS web apps without needing any custom directives for taps/clicks.

Great idea and nice implementation!