How can I check for real touch support on a browser

Today (or very recently) Chrome Beta updated to 17 for me and with it i noticed some funkiness in my web app. I noticed it was because a class was being added to the body element that normally only gets put there if there is touch event support which I check like this:

  try {  
    _device.touch = true;
  } catch (e) {
    _device.touch = false;

And sure enough, i can create and trigger touch events on Chrome 17. First idea i had was, oh, i can check for touch, and see if a mouse click fails, therefore, there’s a mouse, but MouseEvents trigger too.

  • Non-public API usage
  • Lazy loading of image in tableview
  • How to get filesystem path to image cached with SDWebImage (iOS)
  • Swift accessing and updating tableview in container view
  • iOS 7 Weather app expand/collapse transition
  • How can I delete a specific child node in Firebase from UITableViewCell using Swift
  • How else can I check, without user agent sniffing, that it’s an actual, touchable, device, and not just a browser that supports touch events.

    4 Solutions Collect From Internet About “How can I check for real touch support on a browser”


    'ontouchstart' in document.documentElement

    Not that you probably don’t want to change behavior just because a browser ‘supports touch’. Eg. Chrome on Windows now supports touch all the time, even though there won’t necessarily be a touch screen attached. Even if there is a touch screen attached, the user doesn’t necessarily use it, so you need to be careful with what you change.

    So this really comes down to why you want to know:

    1. You want to know whether you’re going to get touchstart/touchmove/touchend events:
      There’s really no way to know this in advance for sure. Eg. the user could plug in a touch screen after your page has loaded. If you might be interested in these events, you should just listen for them.

    2. You want to know if you should display a ‘mobile’ version of your site
      Whether or not the user has touch support is not the right signal for this – eg. a Windows user with a touch screen probably does NOT want your mobile site. You can use UserAgent heurstics, but please give the user a sticky way to switch versions of your site.

    3. You want to know if you should tweak your UI to be more friendly for touch input
      Eg., maybe some buttons should be larger if the user is likely to use touch. In general it may be best to always design for multiple pointer types – after all you have no way to know the user’s pointer preference when they have both touch and mouse. But if you really want to use knowledge of the pointer hardware available as a hint to making the best UI tradeoff, then there are new CSS media queries you can use:

    I added partial support to Chrome for these in Chrome 21 ( As far as I know, no other browser supports them yet.

    ('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch

    easy, don’t.
    if you design the site properly, the only valid reason to test for it is so non-touch browsers, particularly older browsers, don’t thow errors, and depending on how you have implemented touch events, that may not even be an issue (they just won’t fire), however when using a library like hammer.js, you need to create an instance of the hammer object, in an older browser like IE 8 that will throw an error, easy way around this is to just wrap that code in try and catch statements:

    try {
     var Hammer = new HAMMER();
    } catch (err) {
     'do what ever or do nothing, does not support touch or won't work at least anyway'

    at this this will allow all other JavaScript code to continue.