Use FastClick only for items matching selector

[marcovtwout]

I know it's possible with 'needsclick' to make exceptions for fastclicking within the selected layer.

Instead, I'd like to attach fastclick only to selected elements (for example, having class="fastclick"). Is this possible?

[forberg]

It would be nice if the needsclick and fastclick class name could delegate.

Like so:

<div class="foo needsclick">
    <a href="#linkThatNeedsClick">Foo</a>
    <h3><a href="#linkThatNeedsClick">Bar</a></h3>
</div>

[mattcg]

Just out of curiosity, why do so many people want this? I can't think of a reason why I would want this functionality.

[mattcg]

An implementation would involve checking the target using target.matchesSelector('.needsclick, .needsclick *') and/or target.matchesSelector('.fastclick, .fastclick *').

[forberg]

It would come in handy when dealing with a lots elements containing many anchors that needs normal click.

We have lots of preambles on a frontpage that contains maybe 3 - 4 anchor elements.

[mattcg]

Why do these elements need a normal click? Sorry for all the questions, I'm just trying to understand what the root problem is.

[marcovtwout]

For example, in my application I only want to apply fastClick to a set of tabs on top of the page. All other links should be using the default browser behavior.

Why do they need a normal click? I don't know how matured fastClick is right now, but previous implementations of this one and alternatives I used over the past two years had quirky behavior in non-Android or less commonly used browser versions. Due to the nature of the implementation (emulating events based on current browser behavior) I expect this to be a continuous problem, so I like to be selective about which elements will use fastClick.

[dominicwhittle]

I would also like to apply fastclick to specific elements only. In my case it's to improve performance.

The website I'm building has large clickable "cards", each of which has a hover effect. My iPad 2 struggles to scroll up and down the page if I touching a "card" and swipe/scroll from that point. It's fine however, if I scroll by dragging from the narrow margins between cards.

[lauriinc]

Any word on this functionality or a way to do it some way? I also want to assign fastclick only on certain elements because using it causes some problems in the iOS environment and it would be safer to use it only where needed.

[tkorsback]

Same thing here. We're using a off canvas navigation on mobile devices. The problem is that when we use fastclick the user can sometimes accidentally click on a link when scrolling.

[rossholdway]

+1 for this also, would be a really good feature to have.

[cedrickimsarmenta]

+1

[brendanheywood]

+1. I've run into two cases where I want this. Both are to do with mixing and matching with different JS libraries that are already touch happy, but conflict with FastClick and cause mega jank. The other libraries can be scoped down to certain elements but FastClick can't.

[kbav]

+1. Scoping to just certain elements would be a big safety net for the weird behaviors FastClick is struggling with. .needsclick is handy but I'd rather go the opposite way to ease testing.

[axnd]

I'm with @mattcg - I honestly don't see a valid use case for this.

FastClick is not as unstable as these comments would make it seem, we've been successfully using it in production for about 6 months. The only issue we've run into is legacy code that had bound click and touch events on an element causing double execution - these cases are easy to fix by removing the touch handlers.

Introducing a fastclick class will surely litter your codebase with a useless class over time and as your project grows you will be shooting yourself in the foot each time you forget to add the fastclick class.

Lastly the complexity this feature adds to the project will inevitably cause more bugs, making testing even more difficult, and lead to confusion as developers try to understand when to use fastclick vs needsclick and what happens if I mix and match them in the hierarchy.

I vote -1 on this.

[brendanheywood]

My issues aren't with stability just with scoping of behaviour. The fact that FastClick has the 'needsclick' feature is proof that you may not want it everywhere, the only question is a practical one of managing where it works.

Do you start with FastClick everywhere and remove it from selected places, or only add it where you want it?

That choice will depend on each project using it and what other code it is being mixing with. If you only want it in 10% of a project removing it from the other 90% is either a pain or impossible. It would also go a long way if the needsclick check also worked on ancestor elements so you can turn it of for whole chunks of dom.

But the best solution is an optional selector param which switches it to off by default and only get turned on for nodes under the selector:

Simple config which requires .fastclick throughout document:

FastClick.attach(document.body, '.fastclick');

Or a more explicit selector with zero markup changes (avoids the issue @axnd mentioned):

FastClick.attach(document.body, 'nav a, footer a, etc, etc');

[marcovtwout]

Let me try to explain my original question again. The nature of the whole fastclick library is to improve native browser behavior by -emulating- clicks. This alone makes it more unstable than native browser behavior. It might work for (most of) the cases you currently know about, but you can't possibly foresee all possible situations now and in the future.

Second, the fastclick behavior is an improvement in some situations, but not for all. For ALL normal page links, I simply WANT the default browser behavior. The fastclick behavior really is not needed there, so why would I apply it and make those parts of my website possibly more unstable?

I think this is an essential feature and also simple to implement, I like the previous poster's suggestions about this.

Concluding, I think the suggested author's intention that fastclick should usually be applied to everything in the page is wrong, and enough people have indicated their use cases are different.

[jaseemabid]

I had issues with jquery slider when used with fast click. Please make this selective.

[KokoDoko]

I am running a jQuery-based minigame inside a normal webpage. I want to use fastclick only for the game (since touching and clicking needs to be as fast as possible).
I'd love to see an option like this:

FastClick.attach("#gamediv");

[matthew-andrews]

@KokoDoko does adding FastClick to the body cause any problems?

[marcovtwout]

@matthew-andrews Solving certain situations where fastclick does not work is not the purpose of this ticket, can we stay on topic? :) What exactly are the arguments against implementing the proposed solution?

[KokoDoko]

First of all, I did not build the surrounding website of my game. So it seems rather imposing to add a script that changes the functionality of the entire website.
Perhaps, the game could be loaded in an iframe, thereby making sure that fastclick only works on the game, but using iframes has its own implications.
I think the 300ms delay on touchscreens can actually be a good thing. Especially on scrolling pages it helps to prevent a scroll gesture being interpreted as a click. So that's why I'm thinking it would be a good idea to allow fastclick to work only on certain elements.

[rowanbeentje]

You can already selectively invoke FastClick - the default suggested handler is FastClick.attach(document.body), but you can equally make it FastClick.attach(gameElement). What it doesn't currently accept is a selector, because that implies that the selector it's given is maintained in a live-attach fashion...

[jasonday]

Another +1
We are a large site, with complex code (new & legacy). There are plenty of cases where we need to remove the fastclick event because it conflicts with other event delegation and we can't feasibly go through and remove/change all code that conflicts (scope).

[matthew-andrews]

The people have spoken.

I've put something together quickly that combines the event delegation / selective matching features of our tiny DOM Delegation library and FastClick and imaginatively called it Selective FastClick.

Building this is a separate repository means that people who don't want or need the option to selectively target certain elements for FastClick can continue using FastClick as they are now.

The API of the new library should be:

// SelectiveFastClick.attach(/* Parent DOM element to listen for events within - defaulting to document.body */ , /* string or array of strings of selectors to match */);

// In theory, the following *should* all be supported:-
SelectiveFastClick.attach(document.body, '.fastclick');
SelectiveFastClick.attach('.fastclick');
SelectiveFastClick.attach(['button', '.fastclick', 'a']);

Note: I've only just put this together so there may be bugs.

I'm going to close this issue as I think the request has been fulfilled. Please let me know your suggestions for a better name, issues you find or other feedback via the issue tracker over in the Selective FastClick project.

Hope this helps.

[marcovtwout]

Thanks! Is there an easy way to compare the differences between both projects through GitHub? Are there so many changes required that you decided it is worth the extra effort of maintaining a separate repository?

[matthew-andrews]

@marcovtwout - It actually pulls in FastClick as a dependency - so there's very little duplication of code / extra effort of maintaining a separate repository.

The code for selective-fastclick is here:- https://github.com/matthew-andrews/selective-fastclick/blob/master/index.js

[marcovtwout]

Thanks. I don't have much time available to do any rigorous testing, so I'm hoping for other users in this topic to try it out. I'd be happy to use it in production once we have some more feedback on it. :)

[mattCampy]

Has anybody gotten Selective FastClick to work? This feature would be immensely useful.

[matthew-andrews]

@mattCampy could you make a jsbin.com for me to take a look?

[bathindavarinder]

FastClick don't even work with 'textarea' element. It doesn't open keyboard when you click on it, i found a work around for it. Let me know if anybody needs help in that.