11–20 of 32 posts
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.
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'.
This should be of interest as well: https://developers.google.com/mobile/articles/fast_buttons
Thanks for the reference, and thanks to the OP
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 completel…
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.
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.
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 completel…
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 n…
// load fast click if mobile safari
if(navigator.userAgent.match(/(iPhone|iPod|iPad)/i) {
head.js("js/fastclick.min.js", function() {});
}
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.
Earlier quoted context omitted.
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 n…
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
Earlier quoted context omitted.
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 n…
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