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 {
document.createEvent("TouchEvent");
_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.
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.
Try:
'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:
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.
('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With