Is disabling all click events at first touchstart event a good idea?

Question

Making a nice quick-responding website is relatively difficult because of the conflicts between touchstart, tap and the 300ms delayed click.

Ofcourse vclick should fix these issues, but also they seem to have problems fixing it completely. From the documentation:

Warning: Use vclick with caution

Use vclick with caution on touch devices. Webkit based browsers synthesize mousedown, mouseup, and click events roughly 300ms after the touchend event is dispatched. The target of the synthesized mouse events are calculated at the time they are dispatched and are based on the location of the touch events and, in some cases, the implementation specific heuristics which leads to different target calculations on different devices and even different OS versions for the same device. This means the target element within the original touch events could be different from the target element within the synthesized mouse events.

We recommend using click instead of vclick anytime the action being triggered has the possibility of changing the content underneath the point that was touched on screen. This includes page transitions and other behaviors such as collapse/expand that could result in the screen shifting or content being completely replaced.

Now I'm thinking about doing something simpler. Whenever a touchstart event is being triggered I know this is a touch device for sure. I just disable all click events, and start listening to touchstart (or tap) events only. Ignoring the 300ms delayed click events.

Of course there are devices with a mouse and touch, but people using these at the same time seem like a minority to me.

Is this a good idea, or am I missing something in my thinking?

Answer 1

First of… what makes you say that people that use both touch and mouse input are a minority?

The 300ms click delay has been gone a while now on Android when using <meta name="viewport" content="width=device-width">. Unfortunately it can't be removed on iOS because it's a scroll gesture on unzoomable pages that almost nobody seems to be aware of.

I'd say that the best approach is still to support both mouse as well as touch input, despite the 300ms delay on iOS devices. It's dangerous to assume a user will exclusively use touch input when they use it once.

Imagine a user happily using a mouse to navigate. They see something interesting that they want to look at a bit closer so they use a touch gesture to zoom in and all of a sudden mouse clicks don't work anymore. That sounds broken to me.

I just remembered an interesting discussion about detecting a mouse user. Maybe it'll help you see things a bit differently.

Answer 2

Yes, in my honest opinion it is smart way to go. This has proven to be quite a hard problem and when you still combine it to the compatibility problems caused by some really crappy mobile devices which don't follow standards even that bit, it quickly becomes a battle that you can't win. We have adopted a solution close to this, with realization of fact that there might arise problems with poor devices. But after all, you can't satisfy the needs of everybody and the distribution of usage tends to favor those devices (nowadays) that follow the standards.

Also note that you don't need to wait for first touchstart to happen. Instead you can do this trick after DOM is ready and bind the events accordingly.

var isTouchDevice = 'ontouchstart' in document.documentElement;

which is copied from KevBurnsJr's answer.

Also as you most probably already know, you can bind to all kind of events and then check when entering the callback of which type the event actually is with

event.type

Good luck!

Answer 3

It would be a bad idea to disable all click events on the basis of a single touchstart as you suggest. While using both pointers or touch at the same time isn't a common use case. Preventing dual use of mouse/pens and touch isn't a forward compatible approach.

And when you say: "Ignoring the 300ms delayed click events."

I think you make a false assumption on click. You'd still have to synthesize clicks one way or another. touchstart alone isn't a click action. An assumed click happens on touchend, not touchstart. Here is the principle behind detecting clicks early on mobile: https://developers.google.com/mobile/articles/fast_buttons

If you are looking for fastclicks you may want to look into the fastclick script or other fastclick ones on github instead of vclicks.

Answer 4

To avoid issues with people using both touchscreen and mouse with pleasant reactivity I suggest this in JQuery, it works good enough for me:

$elem.on('click touchstart', function(e){
   var $self = $(this);
   if(e.type == 'touchstart'){ 
      $self.mouseenter(); //fire events you still need 
      e.preventDefault();
   }
   /* your code */
});

From my experience it's better than keep the delay on click event and some hazardous comportment through devices, but there's inconvenient too.

On the iPad I tested, it avoids the situation where hover event is triggered on first tap then click event on second tap, but also it seems that the click event fire when you tap near the border of your element and not the touchstart, have to keep it in mind.

Also, it seems not working well with 'tap' event, certainly because it's not well treated yet by JQuery.