FastClick
github.com
github.com
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.
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.
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.
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.
// 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 safariThanks for the reference, and thanks to the OP
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.
https://github.com/kikinteractive/clickable
It has support for:
* "fast" clicking
* managing downstate in CSS (like :active)
* using the native disabled property
* sticky downstates
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 :)
Not really something we can do anything about - it's an edge case.