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 el
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:
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.
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.
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 (crbug.com/123062). As far as I know, no other browser supports them yet.
Try:
'ontouchstart' in document.documentElement
('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch