How to optimize website for touch devices

Question

On a touch device like iPhone/iPad/Android it can be difficult to hit a small button with your finger. There is no cross-browser way to detect touch devices with CSS media queries that I know of. So I check if the browser has support for Javascript touch events. Until now, other browsers haven't supported them, but the latest Google Chrome on dev channel enabled touch events (even for non touch devices). And I suspect other browser makers will follow, since laptops with touch screens are coming. Update: It was a bug in Chrome, so now the JavaScript detection works again.

This is the test I use:

function isTouchDevice() {
    return "ontouchstart" in window;
}

The problem is that this only tests if the browser has support for touch events, not the device.

Does anyone know of The Correct[tm] way of giving touch devices better user experience? Other than sniffing user agent.

Mozilla has a media query for touch devices. But I haven't seen anything like it in any other browser: https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled

Update: I want to avoid using a separate page/site for mobile/touch devices. The solution has to detect touch devices with object detection or similar from JavaScript, or include a custom touch-CSS without user agent sniffing! The main reason I asked, was to make sure it's not possible today, before I contact the css3 working group. So please don't answer if you can't follow the requirements in the question ;)

Solution 1

It sounds to me like you want to have a touch-screen-friendly option, to cover the following scenarios:

1. iPhone-like devices: small screen, touch only
2. Small screens, no touch (you didn't mention this one)
3. Large screens, no touch (i.e. conventional computers)
4. Touch-screen-enabled large screens such as iPad, notebooks/pcs with touch screens.

For case 1 and 2 you will probably need a separate site or a CSS file that eliminates lots of unnecessary content and makes things larger and easier to read/navigate. If you care about case #2 then as long as the links/buttons on the page are keyboard-navigable then case 1 and 2 are equivalent.

For case 3 you have your normal website. For case 4 it sounds like you want clickable things to be bigger or easier to touch. If it's not possible to simply make everything bigger for all users, an alternate style-sheet can provide you with the touch-friendly layout changes.

The easiest thing to do is provide a link to the touch-screen-version of the site somewhere on the page. For well-known touch devices such as iPad you can sniff the user agent and set the touch stylesheet as the default. However I'd consider making this the default for everyone; if your design looks good on the iPad it should look acceptably good on any notebook. Your mouse users with less-than-stellar clicking skills will be pleased to find bigger click targets, especially if you add appropriate :hover or mouseover effects to let users know that things are clickable.

I know you said you don't want to sniff user-agents. But I'd contend that at this time the state of browser support for this is in too much flux to worry about the "Correct" way to do it. Browsers will eventually provide the information that you need, but you will probably find that it will be years before this information is ubiquitous.

Solution 2

Good news! The editor draft of CSS4 Media Queries have included a new media feature 'pointer'.

Typical examples of a ‘fine’ pointing system are a mouse, a track-pad or a stylus-based touch screen. Finger-based touch screens would qualify as ‘coarse’.

/* Make radio buttons and check boxes larger if we
   have an inaccurate pointing device */
@media (pointer:coarse) {
    input[type="checkbox"], input[type="radio"] {
        min-width:30px;
        min-height:40px;
        background:transparent;
    }
}

It's also possible to test the media query from JavaScript:

var isCoarsePointer = (window.matchMedia &&
                       matchMedia("(pointer: coarse)").matches);

Updated Feb. 11th. 2013 On Windows 8 recent versions of Chrome (version 24+) detect touch-hardware when launching the application and expose touch events. Unfortunately if "pointer:coarse" returns false, there is no way to know if it's because pointer media queries are not implemented or because there is a fine pointer. WebKit haven't implemented "pointer:fine" yet, so we can't check that either.

Update Sept. 26th. 2012 Tested in Safari on iOS6 and Chrome on Android 4.1.1 and it's not there yet. 'pointer' and 'hover' media-queries landed in WebKit May 30th. According to the User-Agent, Safari uses WebKit branch 536.26 from April 25th, and Chrome on Android uses and even older one (535.19). Not sure WebKit branches from User-Agent strings are to be trusted, but my test page is not able to detect pointer media queries either. The implementation from May only implements the pointer media query for touch devices, so pointer: fine won't work for devices with a mouse.

Solution 3

Google Chrome has a command line switch for enabling touch events. Disabled by default. So until they enable them for everyone again (hopefully they won't), it's possible to detect touch with the help of javascript like I described in the question..

Update jun 3 2010: This actually got into the stable version on 25th of May 2010 :( Don't know it it was a mistake or not.

Have discussed the issue on the w3c mailing list, but I doubt anything will happen very soon. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html They might discuss this during TPAC in November.

Update sep 30 2010: Supposedly fixed in Chrome 6. Haven't had time to downgrade to stable yet to verify. Since Chrome upgrade automatically this problem should already be gone :)

Read this if you're considering using media queries: http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ and http://www.quirksmode.org/blog/archives/2010/09/more_about_medi.html

Update may 16th 2011: W3C is now working on a Touch Events specification, but more or less refused to hide touch events for terminals without touch hardware. So don't expect the touch event detection to work for long.

Update june 6th 2012: The W3C CSS4 Media Queries (Editors Draft) spec have something very interesting. See my separate answer about this.

Solution 4

I don't know if a standardized media query like Mozilla's will solve the problem by itself. Like one of the Chromium developers said in that discussion you linked, the presence of touch event support in the browser doesn't mean touch events can or will fire, or even if they do, that the user will only want to interact via touch input. Likewise, the presence of touch input support in the device doesn't mean the user will use that method of input - perhaps the device supports mouse, keyboard, and touch input and the user prefers the mouse or some combination of the three input types.

I agree with the Chromium developer that supporting touch events was not a bug in the browser. A good browser should support touch events because it might be installed on a device that supports touch input. It's the website developer's fault that he took the event support to mean the user would be interacting via touch.

It seems we need to know two things: (1) What are all the supported input types on the device (2) What are all the supported event types in the browser

Since we don't know #1 right now, there is one approach proposed by PPK of quirksmode that I like. He talks about it here: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4

Basically, listen for touch events and mouse events, and when they happen, set up the UI accordingly. Obviously that's limiting to the developer. I don't think it's a valid approach to your problem with link size because you don't want to wait for interaction to alter the UI. The whole point is to present a different UI (a larger/smaller link) before any interaction occurs.

I hope you make your proposal and it gets included in CSS3. Until then, as much as it pains me to say it, user agent sniffing looks like the best approach.

p.s. I hope hope hope someone comes here and proves me wrong

Solution 5

No, there is no such thing. CSS has the screen size option, which will allow you to optimize layout, but that's all. There is also media="handheld" but that also doesn't apply to your requirements.

Feature detection might work using javascript, however, there are issues with different events for different devices. PPK (the man behind quirksmode.org) is doing a huge amount of work checking what javascript is possible for each mobile/handheld device, and it's proving that nothing seems to be standard with these devices and yet this STILL doesn't apply to your requirement for touch laptop devices.
(honestly I dont know why you are concerned about a device that isn't even out yet, be pragmatic and worry about it once it's here and you can test it)

PPK's work on mobile browser and touch events, will save you hours. Check it out here

View more solutions

Comments

[gregers]

I think you misunderstood my question. There is no way to include an alternative style sheet for touch devices. If you know how, please enlighten me! You can use media queries to include style sheets for small screens, but how does that help for iPad or laptops with a touch screen? Touch is not the same as mobile.

[Josh K]

I'm assuming there is a list of touch sensitive devices and the browsers that are built in, i.e. Safari. Include an additional CSS file if it's recognized. Touch may not be the same thing as mobile, but really touch sensitivity is going to be mainly based on the device and the calibration, not you.

[Josh Stodola]

@gregers I believe what he is referring to is a completely separate web site that you redirect to when you detect a mobile device. Different markup, different style, different script, same back-end. Wikipedia does this, and so do many other sites.

[gregers]

Small screens is not a problem. The problem is small buttons/links on touch devices - no matter the size of the screen. I know it's possible to detect using user-agent or use a separate site, but that's against all best practices. CSS3 is not final, so we still have a chance to get this as part of CSS3 media queries or similar!

[gregers]

Just look at the rate of new Android phones, and soon laptops with touch screens. Doing user agent sniffing is not an option for me. If this is not possible in browsers today, it's something we need to address to the browser developers! The device manufacturers can calibrate as much as they want. I'm still going to struggle to hit the correct link/button with my finger. Touch devices need bigger buttons/links, and developers need a good way to give them that!

[gregers]

Yes, PPK is doing an awesome job, but it doesn't solve the need I and many other developers have. I'm just want to be sure it's not possible before I contact the people working on css3. As I beleive this should be a part of media queries.

[gregers]

Please read the question before answering ;) "Other than sniffing user agent"

[Jonah]

User agent sniffing is a valid solution in general. I don't see why another solution should be implanted by css3 - that would be redundant

[gregers]

User agent sniffing is not future proof! A rule of thumb is to never use user agent sniffing. It will always come back and bite you. But it's impossible to use the user agent for touch support. The user agent string only contains browser and OS version. So how would you know if it's a laptop with touch screen or not? Just to name a few: Lenovo S10-3t, Acer 1420P, HP TouchSmart, Dell XT2. Both Google Chrome and Firefox are working on touch support.

[Dave Gregory]

Understood. Looks like the working group is still taking Candidate recommendations.. Let us know how that turns out. :D

[gregers]

I accepted your answer because adding a link to the touch version of a site (touch.mydomain.com) is probably the best practice today. As you mentioned, it's also possible to detect some touch devices with user agent, and redirect them automatically. Hopefully we'll get a better way to do this in the future.

[Mr. Shiny and New 安宇]

@gregers: I agree that it would be nice to have a better way. My answer was written with the intention of doing something "right" "today". Maybe one day when there is a better way someone will come along and edit this answer to make it righter. :)

[gregers]

Thank you for a very good comment. Why does your browser need to expose touch events if your device doesn't have hardware support for touch? I kind of like PPK's solution, but I'm not sure how friendly that solution is to a user.

[Michael Hixson]

Can a browser know it's installed on hardware that supports touch? Would any OS inform a browser if the user plugged in a touch input device? I don't know. PPK's solution is the only one where none of this matters. I hear what you're saying about user-friendliness - it would only work when the UI or behavior is result of interaction. For something like a slider bar, this works perfectly. I think YouTube also does this well with their comments (mousing over a comment exposes controls). For your big/small link problem it doesn't work so well, and it does nothing for purely HTML/CSS pages.

[Stuart.Sklinar]

Surely feature detection is the new way to go forwards?

[gregers]

How does tables make anything better for touch devices? If you want relative size there are plenty of better ways to solve that. "HTML tables should only be used to display data in tabular form" - webdesignfromscratch.com/html-css/html-tables

[Mikko Rantalainen]

User agent sniffing is good only for blacklisting stuff. For example, if some browser pretends to support some feature when queried from javascript but the support is too buggy to be usable in the real world, then user agent sniffing is okay for detecting the buggy version. User agent sniffing is not okay for whitelisting stuff because future user agents (from same or different vendors) might support the needed feature but will not "work" because the UA is not included to your whitelist.

[Bastes]

Great news indeed! Your trick was just what I needed to recognize touch devices. Thanks a lot!

[gman]

Seems like it would fail on a tablet with stylus