Modernizr 3.7.1 sets .touchevents on Desktop-Chrome

[BenRichter]

macOS High Sierra (v 10.13.6)
Chrome Version 72.0.3626.121 (64-bit)
Modernizr v3.7.1

After upgrading modernizr, the class .touchevents (instead of .no-touchevents) was set in Chrome.

• Firefox and Safari are working fine.
• Didn't zoom or else
• Incognito-Mode without Plugins has same effect
• Same in colleagues Vivaldi-Browser (chromium)

[rejas]

See #2428: The test detects if the browser is capable of detecting touches, not if the device is a touch device.

[BenRichter]

My bad. I guess there are hundreds of sites using this feature wrong.
In our case we're initiating https://github.com/ftlabs/fastclick to remove click delays on touch devices, if touchevents are enabled. But this will fire two events now... :/

[rejas]

I have to admit I find this confusing too. Maybe it is time to add another test for detecting if the device is touch-capable. https://ctrlq.org/code/19616-detect-touch-screen-javascript seems promising for detecting such devices. What do you think?

[niksy]

Just to chime in - I think feature test should tell if device is actually touch device; I think people expect that from this feature test.

[rejas]

If they expect that they are clearly not reading the documentation ;-)

Yes, this test also clearly needs a cleanup / refinement. But I dont think that changing its scope now would help sicne we dont know how many people use it wrongly / correctly. There for adding another tests (and updating the docs to point to that accordingly) would be the better path IMO

[SlexAxton]

This is one of the oldest and most recurring requests for modernizr. Everyone agrees it would be nice, but no one has ever been able to write a test without a significant amount of false positives.

The short version: there are a slew of devices that support touch events and mouse events (microsoft surfaces). Users even mix and match these events in single interactions with apps. Detecting support for touch doesn’t in anyways guarantee that touch events are going to occur, and visa versa.

(Also mooost devices lie in interesting ways)

[roblarsen]

There's been a lot of discussion here about this very issue. #869 is the most commented issue in the repo.

If you're unfamiliar with the complexity, this remains a good place to start although there are some changes (more complexity!) to the landscape since it was last updated.

As a Surface Pro user (touch! pen! mouse!) I can tell you, web developers screw this interaction up all the time.

[rejas]

So you dont think that adding a new "simple touchdevice" test based on ('ontouchstart' in window) would be an option? It would at least give those people that want to detect a touchdevice a starting point. And yes, I am pretty sure even if we add a BIG THIS TEST IS NOT 100% CORRECT warning sign in the docs/code we'd get open issues... But then we could at least request PRs or tell them that it aint so easy as they think it is....

[roblarsen]

What is a "touch device?" What is a "touch user." It's the wrong question to ask. Asking it and acting on it like it's a binary is usually harmful to end user experience.

Is my Surface Pro with a mouse, a pen and a touchscreen a "touch device?" How about my Note with the pen out? Yes and yes? Okay, maybe. Is it necessarily appropriate to give me _just_ a fat finger interface on those devices? With the Surface Pro? It's the wrong choice and hurts my user experience (people do this all the time) With the Note? It's probably okay.

But, roughly, those devices are very similar- they both have touch capability but can also provide a fine-grained pointer _in the same session_. There are better ways to approach this question.