Modernizr.touch detects touch events not touch devices

[paulirish]

IE Mobile e.g. doesnt expose webkit touch events but is a touch device..

what exactly does Modernizr.touch imply? We should agree so we can document it.

[ryanseddon]

Yes, yes we should. Caniuse.com says Firefox 9+ supports touch but our test says otherwise when comparing to caniuse.com results.

[dmethvin]

I think there is already way too much code around that expects Modernizr.touch to mean Webkit touch events. If Firefox does a good enough job of emulating them then it seems it should be true there too. Microsoft's touch events are [http://blogs.msdn.com/b/ie/archive/2011/09/20/touch-input-for-ie10-and-metro-style-apps.aspx completely different] so I think it would be better to define Modernizr.pointer or Modernizr.mspointer for them.

[paulirish]

I like dave's proposal.

We tried capturing firefox touch in the Modernizr.touch test and it led to bad code forking.
We need to test and expose each unique touch model, however ridiculous that is.

see also jquery's upcoming blog post.

[dmethvin]

Yes, I am afraid there are dark days ahead when it comes to apps handling touch events. The Webkit model would have been fine with me but it seems unlikely to gain a W3C blessing now. We can blame Apple's foot-dragging for this fragmentation.

[ryanseddon]

Yep this will be good to breakout touch into a plugin since it'll get huge testing for all variants.

I'm pretty sure caniuse.com is wrong when it says firefox supports touch I have been poking around fennec and it doesn't support touch and they deprecated their MozTouch in 4.0

[lauripiispanen]

ref #448 - I agree with the second point of optimizing the layout with media queries. Any sufficiently small screen can be handled with those.

But in any case, windows phones currently don't send any events whatsoever (not even MSPointerEvents, they are slated for later versions), so you would need to detect that and render e.g. clickable controls vs swipeable ones. So for the current breed of windows phones, "touch" being true is valid in that the input method is a touch one and you need bigger manipulation controls for the user to hit. Then again, "touch" being false is valid in that the browser doesn't send any meaningful information whatsoever on the user's touch input.

[paulirish]

So there is

• Event model detection: so i can fork my JS event binding code to do the right thing
• Touch device detection: so i can optimize my layout and interaction for fingers.

I think media queries tackle the second, for now... but so shall we just focus on touch event models?

[lauripiispanen]

I agree that's a good strategy. Having Modernirz.touch return the applicable touch event model, and null/false if no touch event model is present should be enough cue to add non-touch manipulable controls on the page.

[paulirish]

Modernizr.touch // 'apple'
Modernizr.touch // 'pointer'
Modernizr.touch // false

How about that?

[dmethvin]

Should that be 'webkit'?

Do we have an idea how people are using Modernizr.touch as far as its implications? I would bet a lot of it today expects it to mean Webkit touch events and would break otherwise.

[ryanseddon]

@dmethvin yeah very good point that's how a lot of people would be using it. Not sure how we could handle it, the docs clearly state that it will return true in situtations where it's not a touchscreen device but does support touch.

[paulirish]

related tickets:

• Non-touch BlackBerry devices return false positive for Modernizr.touch #372 Non-touch BlackBerry devices return false positive for Modernizr.touch
• Modernizr.touch == false on Windows Phone #448 Modernizr.touch == false on Windows Phone
• False positive at touch events on Nokia N900 (Maemo) #220 False positive at touch events on Nokia N900 (Maemo)
• Lenovo Thinkpad T400 should not be a 'touch' device #339 Lenovo Thinkpad T400 should not be a 'touch' device

[paulirish]

Related: http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx includes msft's proposed feature detect

[masteroleary]

Yikes, this is too complicated for me. Props to you all.

[paulirish]

Related: http://code.google.com/p/chromium/issues/detail?id=152149

worth reading:

At the moment (to avoid broadly breaking sites like you describe) touch event support is enabled dynamically at run-time when we detect a touch screen. So any site that assumes that touch event support implies a mobile device (or lack of mouse support generally) will be broken on Windows/ChromeOS with a touch screen. Also, mobile devices like blackberry (and to a lesser extent Android) support mice in addition to a touch screen - so it's never really been true that touch event support implies you can ignore mouse events.

Also, I believe you're conflating the concept of "the browser supports touch events" and "the user has a touch screen". Just because there is currently no touch screen on a device, doesn't mean chrome shouldn't support touch events. See issue 159527 for more discussion.

Obviously we have a long way to go to make it standard practice and easy for websites to support touch events on desktop devices, but with the rise in popularity of touchscreen laptops (eg. with Win8) this is going to be an important area of focus.

[paulirish]

Confirmation that the Chrome team added support for pointer and hover media queries to webkit and enabled Chromium to appropriately enable them when it discovers a touch screen. It's either now (or very soon) available in desktop Chrome (Windows 8 in particular), and Chrome for Android.

It's worth pointing out some gotchas:

• a touch screen could be dynamically be added via a KVM
• there are an increasing number of scenarios where there is both a touch screen and a pointing device.

---

To avoid confusion, I expect us to deprecate Modernizr.touch as people will consider it as "touch device". We will introduce something like Modernizr.touchevents and Modernizr.touchevents.w3c & Modernizr.touchevents.pointer

[paulirish]

As for pointer/hover media queries.. each WebKit port needs to enable them individually-- the embedding environment needs to inform webkit what hardware the device has.. As such, it's possible the next releases of Blackberry, Nokia, iOS, and other webkit ports may not have these media queries enabled yet. If you have friends there, make sure they know you want them. :)

[ryanseddon]

So would Modernizr.touchevents.pointer indicate a true on the coarse MQ? And would the top level Modernizr.touchevents indicate it supports either the w3c events or pointer coarse?

[paulirish]

Modernizr.touchevents would be true if either w3c or pointer were
implemented.

and then the more detailed one would indicate which model(s) is/are
implemented.

coarsepointer probably needs its own detect, maybe named that

On Mon, Jan 7, 2013 at 5:23 PM, Ryan Seddon notifications@github.comwrote:

So would Modernizr.touchevents.pointer indicate a true on the coarse MQ?
And would the top level Modernizr.touchevents indicate it supports either
the w3c events or pointer coarse?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/548#issuecomment-11980446.

[stucox]

Thanks for these updates @paulirish.

Does it really make sense for a pointer detect to fall under Modernizr.touchevents though? The whole point of the PointerEvent spec is it's independent of touch, mouse, etc.

Wouldn't simply Modernizr.touchevents and Modernizr.pointerevents be cleaner and more suitable?

Hopefully Kinect-style motion sensing input devices would fire PointerEvents too, but by definition don't involve touching anything!

---

Also, none/fine/coarse values from the media query is a feature of the device again, not the browser. It's also a dynamic feature - as devices may be plugged/unplugged - where as Modernizr is "static" in that it's just run on page load.

My opinion would be that Modernizr should stick to detecting static browser support for PointerEvents and TouchEvents, while media queries can be used to determine, dynamically, whether or not a certain input device capability is present. So no need for Modernizr.coarsepointer or similar.

Encouraging this pattern would (eventually) mean browsers no longer have to enable/disable touch-related APIs at runtime based on the input devices connected, and would encourage developers to consider input modes as a dynamic feature, like we already do for screen size.

I love the idea of opening a web page on a tablet at home, using a mouse & keyboard with it, unplugging it to head out the door and the UI automatically switching to a touch-friendly variant.

[paulirish]

I like everything you just said.

On Tue, Jan 8, 2013 at 12:33 AM, Stu Cox notifications@github.com wrote:

Thanks for these updates @paulirish https://github.com/paulirish.

Does it really make sense for a pointer detect to fall under
Modernizr.touchevents though? The whole point of the PointerEvent spec is
it's independent of touch, mouse, etc.

Wouldn't simply Modernizr.touchevents and Modernizr.pointerevents be
cleaner and more suitable?

Hopefully Kinect-style motion sensing input devices would fire

PointerEvents too, but by definition don't involve touching anything!

Also, none/fine/coarse values from the media query is a feature of the
device again, not the browser. It's also a dynamic feature - as devices may
be plugged/unplugged - where as Modernizr is "static" in that it's run on
page load.

My opinion would be that Modernizr should stick to detecting static
browser support for PointerEvents and TouchEvents, while media queries
can be used to determine, dynamically, whether or not a certain input
device capability is present. So no need for Modernizr.coarsepointer or
similar.

Encouraging this pattern would (eventually) mean browsers no longer have
to enable/disable touch-related APIs at runtime based on the input devices
connected, and would encourage developers to consider input modes as a
dynamic feature, like we already do for screen size.

I love the idea of opening a web page on a tablet at home, using a mouse &
keyboard with it, unplugging it to head out the door and the UI
automatically switching to a touch-friendly variant.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/548#issuecomment-11988620.

[dmethvin]

Encouraging this pattern would (eventually) mean browsers no longer have to enable/disable touch-related APIs at runtime based on the input devices connected, and would encourage developers to consider input modes as a dynamic feature, like we already do for screen size.

🍰

Pointer choices should just be considered part of a responsive design.

[ryanseddon]

@stucox well said and I agree with everything. 🤘

[KuraFire]

I agree with everything @stucox suggested as well. Modernizr.touchevents and Modernizr.pointerevents is a good solution for this finicky issue. And keeping Modernizr itself focused on static feature detection, rather than dynamic changes, works for me.

[beany-vu]

We can you if(Modernizr.pointerevents) {// handler for point event} to check if user touch on screen of Surface?
Btw, nice to meet you, @paulirish . You are my idol :D

[jiji262]

So how to detect touch devices with Javascript?

[matte00]

@jiji262

let supportsTouch = false;
if ('ontouchstart' in window) // iOS & android
    supportsTouch = true;
else if (window.navigator.msPointerEnabled) // Win8
    supportsTouch = true;
else if ('ontouchstart' in document.documentElement) // Controversal way to check touch support
    supportsTouch = true;

if (supportsTouch) {
    console.log('touch device');
}

[roblarsen]

EVERYTHING YOU (N)EVER WANTED TO KNOW ABOUT TOUCH AND POINTER EVENTS