Modernizr.touch detects touch events not touch devices #548

Closed
paulirish opened this Issue Apr 5, 2012 · 44 comments

Comments

Projects
None yet
@paulirish
Member

paulirish commented Apr 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Apr 7, 2012

Member

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

Member

ryanseddon commented Apr 7, 2012

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

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Apr 7, 2012

Contributor

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.

Contributor

dmethvin commented Apr 7, 2012

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Apr 7, 2012

Member

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.

Member

paulirish commented Apr 7, 2012

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

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Apr 7, 2012

Contributor

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.

Contributor

dmethvin commented Apr 7, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Apr 9, 2012

Member

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

Member

ryanseddon commented Apr 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@lauripiispanen

lauripiispanen Apr 25, 2012

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.

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Apr 26, 2012

Member

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?

Member

paulirish commented Apr 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@lauripiispanen

lauripiispanen Apr 26, 2012

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.

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Apr 26, 2012

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

How about that?

Member

paulirish commented Apr 26, 2012

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

How about that?

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Apr 26, 2012

Contributor

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.

Contributor

dmethvin commented Apr 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Apr 26, 2012

Member

@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.

Member

ryanseddon commented Apr 26, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish May 11, 2012

Member

related tickets:

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

paulirish commented May 11, 2012

related tickets:

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

This comment has been minimized.

Show comment
Hide comment
Member

paulirish commented Jul 12, 2012

@masteroleary

This comment has been minimized.

Show comment
Hide comment
@masteroleary

masteroleary Nov 12, 2012

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

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

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 4, 2013

Member

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.

Member

paulirish commented Jan 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 7, 2013

Member

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

Member

paulirish commented Jan 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 7, 2013

Member

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. :)

Member

paulirish commented Jan 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Jan 8, 2013

Member

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?

Member

ryanseddon commented Jan 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 8, 2013

Member

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/Modernizr/Modernizr/issues/548#issuecomment-11980446.

Member

paulirish commented Jan 8, 2013

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/Modernizr/Modernizr/issues/548#issuecomment-11980446.

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Jan 8, 2013

Member

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.

Member

stucox commented Jan 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 8, 2013

Member

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/Modernizr/Modernizr/issues/548#issuecomment-11988620.

Member

paulirish commented Jan 8, 2013

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/Modernizr/Modernizr/issues/548#issuecomment-11988620.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jan 8, 2013

Contributor

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.

Contributor

dmethvin commented Jan 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Jan 8, 2013

Member

@stucox well said and I agree with everything. 🤘

Member

ryanseddon commented Jan 8, 2013

@stucox well said and I agree with everything. 🤘

@KuraFire

This comment has been minimized.

Show comment
Hide comment
@KuraFire

KuraFire Jan 8, 2013

Member

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.

Member

KuraFire commented Jan 8, 2013

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.

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Jan 28, 2013

Member

Slight problem with the plan above: we already have Modernizr.pointerevents for the CSS pointer-events property.

So... Modernizr.domtouchevents and Modernizr.dompointerevents? Or just dompointerevents and leave touchevents?

Member

stucox commented Jan 28, 2013

Slight problem with the plan above: we already have Modernizr.pointerevents for the CSS pointer-events property.

So... Modernizr.domtouchevents and Modernizr.dompointerevents? Or just dompointerevents and leave touchevents?

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Jan 28, 2013

Member

Or break more apis and move CSS pointer-events (to csspointerevents)
because it's a niche feature that likely many users aren't using.

Damn it. :(

Member

paulirish commented Jan 28, 2013

Or break more apis and move CSS pointer-events (to csspointerevents)
because it's a niche feature that likely many users aren't using.

Damn it. :(

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Jan 28, 2013

Member

Yep. Incoming major version number... now's as good a time as any to tidy things like this up.

Member

stucox commented Jan 28, 2013

Yep. Incoming major version number... now's as good a time as any to tidy things like this up.

@ryanseddon

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Jan 29, 2013

Member

I'd go for breaking css pointer-events maybe even have a console.warn?

Member

ryanseddon commented Jan 29, 2013

I'd go for breaking css pointer-events maybe even have a console.warn?

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Jan 29, 2013

Member

console.warn on... Modernizr.pointerevents? Not sure if I like giving a warning to people who are using the new API - highly annoying to the many, for the benefit for the few who didn't read the release notes; very few if the CSS pointer-events test is indeed rarely used.

Member

stucox commented Jan 29, 2013

console.warn on... Modernizr.pointerevents? Not sure if I like giving a warning to people who are using the new API - highly annoying to the many, for the benefit for the few who didn't read the release notes; very few if the CSS pointer-events test is indeed rarely used.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jan 29, 2013

Contributor

for the benefit for the few who didn't read the release notes

😿 Why can't jQuery users be avid readers like Modernizr users? 😉

But seriously, i like re-purposing the name since I suspect it will be much more commonly used. Maybe we can lobby to get the CSS pointer events renamed.

Contributor

dmethvin commented Jan 29, 2013

for the benefit for the few who didn't read the release notes

😿 Why can't jQuery users be avid readers like Modernizr users? 😉

But seriously, i like re-purposing the name since I suspect it will be much more commonly used. Maybe we can lobby to get the CSS pointer events renamed.

@ryanseddon

This comment has been minimized.

Show comment
Hide comment
@ryanseddon

ryanseddon Jan 29, 2013

Member

yeah ok probably not my best idea lets just make it bold in release notes that pointer-events means something else now.

Member

ryanseddon commented Jan 29, 2013

yeah ok probably not my best idea lets just make it bold in release notes that pointer-events means something else now.

@ghost ghost assigned stucox Jan 29, 2013

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Jan 29, 2013

Member

I'll put together a PR for this. Has anyone made a start on any 3.0 release notes yet?

Member

stucox commented Jan 29, 2013

I'll put together a PR for this. Has anyone made a start on any 3.0 release notes yet?

@psullivan6 psullivan6 referenced this issue in mhulse/jquery-megawhale Mar 22, 2013

Open

Chrome menu touch issue #27

@nathggns

This comment has been minimized.

Show comment
Hide comment
@nathggns

nathggns Mar 27, 2013

So what is the recommended way to detect touch now?

So what is the recommended way to detect touch now?

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Mar 27, 2013

Member

You can't reliably. Alternative approaches depend on your use case — but this HTML5 Rocks article is well worth a read.

Member

stucox commented Mar 27, 2013

You can't reliably. Alternative approaches depend on your use case — but this HTML5 Rocks article is well worth a read.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Mar 27, 2013

Contributor

After all that was said, you got to the bottom and used a vague term like "detect touch". You'll need to be more specific. Detect the potential for the device to generate WebKit touch events? Detect the ability to generate Microsoft pointer events? Detect a device capable of generating any sort of events when its screen is touched, without regard for how it's exposed in JavaScript? Detect a touch-capable device that (currently or eternally) has no other means of interaction such as a mouse or physical keyboard? The info in #869 may be helpful and #805 mentions the new touchevents vs pointerevents split.

Contributor

dmethvin commented Mar 27, 2013

After all that was said, you got to the bottom and used a vague term like "detect touch". You'll need to be more specific. Detect the potential for the device to generate WebKit touch events? Detect the ability to generate Microsoft pointer events? Detect a device capable of generating any sort of events when its screen is touched, without regard for how it's exposed in JavaScript? Detect a touch-capable device that (currently or eternally) has no other means of interaction such as a mouse or physical keyboard? The info in #869 may be helpful and #805 mentions the new touchevents vs pointerevents split.

@nathggns

This comment has been minimized.

Show comment
Hide comment
@nathggns

nathggns Mar 27, 2013

Basically, any handheld device where the main input type is via a touch sensitive screen.

Nathaniel Higgins
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, 27 March 2013 at 17:32, Dave Methvin wrote:

After all that was said, you got to the bottom and used a vague term like "detect touch". You'll need to be more specific. Detect the potential for the device to generate WebKit touch events? Detect the ability to generate Microsoft pointer events? Detect a device capable of generating any sort of events when its screen is touched, without regard for how it's exposed in JavaScript? Detect a touch-capable device that (currently or eternally) has no other means of interaction such as a mouse or physical keyboard? The info in #869 (#869) may be helpful and #805 (#805) mentions the new touchevents vs pointerevents split.


Reply to this email directly or view it on GitHub (#548 (comment)).

Basically, any handheld device where the main input type is via a touch sensitive screen.

Nathaniel Higgins
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, 27 March 2013 at 17:32, Dave Methvin wrote:

After all that was said, you got to the bottom and used a vague term like "detect touch". You'll need to be more specific. Detect the potential for the device to generate WebKit touch events? Detect the ability to generate Microsoft pointer events? Detect a device capable of generating any sort of events when its screen is touched, without regard for how it's exposed in JavaScript? Detect a touch-capable device that (currently or eternally) has no other means of interaction such as a mouse or physical keyboard? The info in #869 (#869) may be helpful and #805 (#805) mentions the new touchevents vs pointerevents split.


Reply to this email directly or view it on GitHub (#548 (comment)).

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Mar 27, 2013

Member

The details of the input mechanisms simply aren't currently made available to apps running in the browser.

So "assume nothing" tends to be the best advice at the moment. As well as the HTML5 Rocks article, this is worth a read: http://globalmoxie.com/blog/desktop-touch-design.shtml.

Member

stucox commented Mar 27, 2013

The details of the input mechanisms simply aren't currently made available to apps running in the browser.

So "assume nothing" tends to be the best advice at the moment. As well as the HTML5 Rocks article, this is worth a read: http://globalmoxie.com/blog/desktop-touch-design.shtml.

@stucox

This comment has been minimized.

Show comment
Hide comment
@stucox

stucox Mar 27, 2013

Member

Btw, we've got a note in #805 to document the touch -> touchevents / pointerevents change, so I think we can close this.

@nathggns - feel free to open a new issue to discuss this more.

Member

stucox commented Mar 27, 2013

Btw, we've got a note in #805 to document the touch -> touchevents / pointerevents change, so I think we can close this.

@nathggns - feel free to open a new issue to discuss this more.

@kuus

This comment has been minimized.

Show comment
Hide comment
@kuus

kuus May 6, 2013

It of course depends on lot of cases, but I found handy the following checks (n addition to Modernizr) to force the no-touch beahvior:

if {( 
        (window.location.host == 'apps.facebook.com') || // in the facebook app it's difficult to manage media queries (cause of the sidebar) so in desktop devices with touch screen it's tricky
        (window.screen.width > 1279 && window.devicePixelRatio == 1) || // this number could be probably 1281, there are no so many mobile devices with more than 1280 and pixelRatio equal to 1 (i.e. retina displays are equal to 2...)
        (window.screen.width > 1000 && window.innerWidth < (window.screen.width * .9)) || // this checks in the end if a user is using a resized browser window which is not common on mobile devices
        (window.screen.width > 1000 && !this.browser.mobile) // this.browser.mobile is a custom check that can use for instance a common jquery plugin for browser detection
    ) {
        // then add a class to html
        $('html').addClass('force-no-touch');
    }

then in the css applying the .no-touch class (modernizr), together with the custom .force-no-touch class

kuus commented May 6, 2013

It of course depends on lot of cases, but I found handy the following checks (n addition to Modernizr) to force the no-touch beahvior:

if {( 
        (window.location.host == 'apps.facebook.com') || // in the facebook app it's difficult to manage media queries (cause of the sidebar) so in desktop devices with touch screen it's tricky
        (window.screen.width > 1279 && window.devicePixelRatio == 1) || // this number could be probably 1281, there are no so many mobile devices with more than 1280 and pixelRatio equal to 1 (i.e. retina displays are equal to 2...)
        (window.screen.width > 1000 && window.innerWidth < (window.screen.width * .9)) || // this checks in the end if a user is using a resized browser window which is not common on mobile devices
        (window.screen.width > 1000 && !this.browser.mobile) // this.browser.mobile is a custom check that can use for instance a common jquery plugin for browser detection
    ) {
        // then add a class to html
        $('html').addClass('force-no-touch');
    }

then in the css applying the .no-touch class (modernizr), together with the custom .force-no-touch class

@eladzlot eladzlot referenced this issue in minnojs/minno-time Apr 29, 2014

Closed

Managing touch detection #12

bjjb added a commit to bjjb/sceitse that referenced this issue Jan 19, 2015

Mobile version
Lets you draw with touches. There's also a manifest.webapp for open web apps
(such as for Firefox OS). Modernizr is used for detecting whether the device
supports touches, but this is _not_ 100% reliable, yet:

Modernizr/Modernizr#548

Currently, the points are 15px off on the Y axis.

patrickkettner pushed a commit to patrickkettner/Modernizr that referenced this issue Feb 22, 2015

Merge pull request #800 from stucox/548-touch
Modernizr.touch changes, as per #548

patrickkettner pushed a commit to patrickkettner/Modernizr that referenced this issue Feb 22, 2015

Merge pull request #800 from stucox/548-touch
Modernizr.touch changes, as per #548

@scurker scurker referenced this issue in jonthornton/jquery-timepicker Jul 29, 2015

Closed

disableTouchKeyboard can prevent focus on non-touch devices #413

@shawnbot shawnbot referenced this issue in RTICWDT/college-scorecard Sep 5, 2015

Merged

Switches from drawer to dropdowns for search refinement and filters #1008

5 of 5 tasks complete

@nylen nylen referenced this issue in Automattic/wp-calypso Dec 10, 2015

Closed

Framework: hasTouch() considered harmful #1479

@pzi pzi referenced this issue in thefrontiergroup/rails-template Aug 16, 2016

Closed

Modernizr.touch was deprecated #136

@albell albell referenced this issue in mediaelement/mediaelement Sep 23, 2016

Closed

Reduce CSS selector specificity? #1849

@Alsciende Alsciende referenced this issue in Alsciende/netrunnerdb Oct 13, 2016

Closed

No tooltip on some non-touch devices #61

@Marina-L-Stoyanova Marina-L-Stoyanova referenced this issue in IgniteUI/ignite-ui Nov 24, 2016

Closed

Researching modernizr touch events #546

@beany-vu

This comment has been minimized.

Show comment
Hide comment
@beany-vu

beany-vu May 23, 2017

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

beany-vu commented May 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jiji262

jiji262 Aug 4, 2017

So how to detect touch devices with Javascript?

jiji262 commented Aug 4, 2017

So how to detect touch devices with Javascript?

@matte00

This comment has been minimized.

Show comment
Hide comment
@matte00

matte00 Mar 21, 2018

@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');
}

matte00 commented Mar 21, 2018

@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');
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment