The past couple of years have seen numerous new web-capable mobile devices arise, including Apple’s iPhone and its Safari browser, the creation of Google’s Android platform and Webkit-based browser, the rise of so called “full web” browsers (Nokia’s S60, Opera Mobile and Opera Mini, among others), the early development of Firefox’s mobile version, and more. These mobile browsers improve users’ experiences, giving them access to websites formerly off-limits to most mobile devices. Indeed, as a 2008 Nielsen Media Research report highlighted, mobile devices have increased traffic by an average of 13% across several popular websites.

Article Continues Below

Ideally, site authors would be able to meet the growing demand for a quality mobile experience without changing a line of code. But the reality is that a site designed specifically with mobility in mind will always provide a much better user experience to mobile users, even when they are equipped with the device du jour. It’s not merely a question of network costs and delays or memory and CPU limitations. Rather, the mobile experience merits its own design, as discussed in a growing body of literature, including the W3C’s very own Mobile Web Best Practices, released in July 2008 as a W3C Recommendation. The formula for a mobile experience provided by Little Springs Design sums up the goal nicely: mobilize, don’t miniaturize. Mobile users operate in a very different usage context than PC users, and providing them with an experience customized to their needs is likely to be the best service you can offer to them.

If you’re just getting started with mobile design, you may face a number of hurdles, including the cost or technical challenge of designing and maintaining a second site—or a simple lack of understanding of how people on the go might use your site. This article discusses a first step toward mobile design that uses CSS to maximize interoperability across platforms. By starting simple, you can provide a decent initial experience, solicit user feedback, and iterate toward a more mobile-friendly design. This is the approach we are taking in our redesign of the W3C site.

Back in 2004, Elika Etemad and Jorunn Newth offered advice on “Pocket-Sized Design,” relying on handheld style sheets to work around some of the usability challenges of mobile devices. For instance, their solution sought to eliminate horizontal scrolling, which can be tiresome on a small device.

Recent browsers tend to avoid that problem by offering a zooming interface that allows users to focus on a specific part of a page. These zooming capabilities certainly offer advantages, especially for users who are already familiar with the website. However, zooming in and out triggers a shift in the viewport, which can confuse users and doesn’t solve the problems of first-time visitors.

Due to these zooming difficulties, and perhaps more importantly, to the scrolling difficulties users of older mobile browsers are likely to encounter, offering a linear view (rather than multi-column layout) remains good advice. Unfortunately, relying only on handheld style sheets to achieve this effect is not sufficient for the recent evolution in the mobile browser market.

screen style sheets strike back#section2

As early as 1998, the HTML 4 specification offered ways to link to different style sheets depending on the devices targeted, including handheld media:

<link rel="stylesheet" href="screen.css" media="screen"/>

<link rel="stylesheet" href="handheld.css" media="handheld"/>

CSS included a similar feature via @media :

@media screen { /* rules for computer screens */ }

@media handheld { /* rules for handheld devices */ }

and through a parameter with @import :

@import "screen.css" screen; @import "handheld.css" handheld;

Many mobile browsers have implemented this feature, but in different ways:

Some read only the handheld style sheet. Some read only the handheld style sheet if there is one, but default to the screen style sheet otherwise. Some read both the handheld style sheet and the screen style sheet. Some read only the screen style sheet.

The last of these can hardly be called an interpretation of the specification. It is my understanding, based on discussions with some of the vendors that implemented this approach, that they did so because they believed that handheld style sheets were less well-designed and maintained than their screen counterparts, and provided an inferior experience to the users.

Recently, Opera’s mobile browsers (Mobile and Mini), two implementations of the rather compelling option two above, switched the default mode to use the screen style sheets, leaving it as a user preference to use the previous behavior.

Most (if not all) of the newest mobile browsers, as part of their “full web” motto, simply ignore handheld style sheets, leaving those who had hopes for the CSS approach out in the cold. Or so it seems.

Media queries: a new hope#section3

Recent versions of Safari and Opera implement CSS Media Queries, a specification that is still in development at the W3C. CSS Media Queries offer more than the simple list of CSSMedia Types. They allow authors to customize a style sheet based on some well-known properties, such as the size of the screen that is rendering the page.

As an example, the following specifies a style sheet to be used by the iPhone’s browser and not any PC browser using (as presented by Craig Hockenberry in A List Apart ):

<link rel="stylesheet" href="handheld.css" media="only screen and (max-device width:480px)"/>

There are good reasons to hope that the number of recent mobile browsers supporting this will increase, if only due to the iPhone’s visibility.

How browsers behave#section4

The following table summarizes how various popular mobile web browsers behave today. Most of the information comes from the raw data that W3C’s mobile test harness collects on how mobile browsers react to CSS media types and media queries.

How various browsers react to CSS Media Types CSS Behavior Browsers Reading only handheld style sheets OpenWave browser, Nokia lite-web browsers, Netfront (configuration dependent), Digia, BlackBerry browser, Opera Mini until v4, Opera Mobile until v9 Reading both handheld and screen style sheets Palm’s Blazer, Nokia S40 browser, IEMobile 6.x and 8.x Reading only screen style sheets with Media Query support iPhone’s Safari, Opera Mobile starting v9, Opera Mini starting v4 Reading only screen style sheets without Media Query support Nokia S60 browser, Netfront (configuration dependant), Teleqa Q7, IEMobile 7.x

Given this diversity, you might immediately ask how many style sheets you’ll need to create a usable mobile user experience. And how can one accommodate the large number of users who access the web through mobile browsers that in some way implement the CSS Media Types technique?

These aren’t the style sheets you’re looking for #section5

I propose a technique for using style sheets that ensures that most mobile browsers will use rules targeted for mobile devices and avoid non-mobile friendly rules. PC browsers will read a style sheet designed for them. The caveat of the first goal is that it will not work with mobile browsers that apply only screen style sheets and do not implement CSS Media Queries. It will work with all versions of Opera (both Mobile and Mini), Safari on the iPhone, Palm’s Blazer browser, IEMobile, and with a fair number of other browsers (more details on support below).

Non-mobile friendly CSS properties typically include:

float and display : because these properties are traditionally used to create multi-column layouts, they tend to require mobile users to scroll or zoom,

and : because these properties are traditionally used to create multi-column layouts, they tend to require mobile users to scroll or zoom, padding and margin : since screen real estate is limited on mobile devices, you will want to reduce or remove most of these on mobile screens, and

and : since screen real estate is limited on mobile devices, you will want to reduce or remove most of these on mobile screens, and background-image : images used for decorating a website for PC browsers tend to be pretty big and have limited use in mobile contexts, so they probably ought to be removed or replaced for mobile browsers.

The idea is similar to Eric Meyer’s reset CSS technique:

define a style sheet screen.css for PC browsers,

for PC browsers, define a style sheet antiscreen.css to cancel any non-mobile friendly effects set in screen.css ,

to cancel any non-mobile friendly effects set in , tie these two style sheets together into a core.css style sheet, à la: @import url("screen.css"); @import url("antiscreen.css") handheld; @import url("antiscreen.css") only screen and (max-device-width:480px);

style sheet, à la: define a style sheet handheld.css with additional styling for mobile browsers, and

with additional styling for mobile browsers, and link them in the document as follows: <link rel="stylesheet" href="core.css" media="screen"/> <link rel="stylesheet" href="handheld.css" media="handheld, only screen and (max-device-width:480px)"/> (or through similar @media blocks or @import directives).

Browser behavior CSS Behavior core

.css screen

.css antiscreen

.css handheld

.css Result PC Browsers read read not read not read screen.css Reading only handheld style sheet not read not read not read read handheld.css Reading both handheld and screen style sheet read read read read screen.css + antiscreen.css + handheld.css Reading only screen style sheets with Media Query support read read read read screen.css + antiscreen.css + handheld.css Reading only screen style sheets without Media Query support read read not read not read screen.css

Mobile browsers that only read the handheld style sheet will never see the potentially harmful CSS properties defined in screen.css . Mobile browsers that read screen style sheets, and handheld or media queries style sheets will not be affected by the harmful properties in screen.css , since they’re canceled by antiscreen.css . Finally, PC browsers will happily ignore both antiscreen.css and handheld.css .

One practical problem remains: if your screen.css style sheet is long and regularly modified, the creation and maintenance of antiscreen.css can be quite a challenge. Who wants to find out which CSS rules include one of the noted properties among the thousands of properties potentially set in a rich style sheet? And who wants to maintain such a list manually?

Fortunately, computers do. If your browser supports the DOM Level 2 Style specification, you can use a script run from your browser on a given page (and more easily so through this bookmarklet) to identify which style sheets in the page you want to cancel.

Sir, the possibility of successfully navigating the mobile user-agent field is approximately 3720 to 1 #section6

This technique addresses the needs of a reasonable number of mobile browsers, including some of the most popular ones. But what can be done for mobile browsers that do not read handheld style sheets, or parse CSS Media Queries? Short of ignoring them, there are two options.

Use JavaScript to force them to read handheld style sheets (given that the browsers in this category are fairly recent ones, they are pretty likely to have a reasonable level of support for JavaScript). Or, rely on server-side techniques to give them the handheld style sheet when they request the screen one.

In both cases, the main drawback—and the reason I don’t recommend trying to use this technique for all mobile devices—is that you will have to explicitly match the user-agent headers sent by the browser. A user-agent header is the name that a browser (mobile or not) sends to the web server when requesting a given page, and which usually identifies a given browser on a given platform. You can see a fairly extensive list of these user-agent headers at user-agents.org.

The problem with relying on these headers is that there are a lot of different browser vendors, and many different browser versions. Maintaining an exhaustive list of user agents is tedious and error-prone, since new browsers and devices are released all the time. There are existing solutions that allow web developers to use external sources for this type of data (e.g., through the W3C’s Device Description Repository API), but given that our goal is to keep it simple, they would clearly fall out of the scope of this article.

In our case, we need to match only a fairly limited number of browsers, and hopefully, that number will not grow much over time, provided people use CSS Media Queries. Johann Burkard provides an example of how to achieve this effect with JavaScript based on a test on the navigator.userAgent property.

To achieve a similar effect with server-side technologies on an Apache server, we use a Rewrite Rule:

# This rewrite rule should be applied in the directory # of the screen.css style sheet # For Series60 browsers RewriteCond {HTTP:User-Agent} Series60 # we redirect screen.css to the handheld stylesheet RewriteRule ^screen.css$ /path/to/handheld/stylesheet/ handheld.css [R=permanent,L] # We set the Vary header on screen.css # to make sure HTTP Cache pays attention to the User-Agent # header as required by the HTTP specification Header add Vary User-Agent

Size matters not. Look at me. Judge me by my size, do you? #section7

In summary…

mobile browsers are becoming more powerful and more widespread,

there are still plenty of not-so powerful mobile browsers, and even powerful ones create usability challenges,

although a mobile-specific user experience will serve your users’ needs better, a mobile-friendly website is better than nothing, and

the antiscreen technique (combined with a script to generate it) allows you to create mobile-friendly style sheets that will work across a large number of mobile browsers.

Do you know of other CSS techniques that address the specific constraints of mobile web browsers? Please share them in the comments, on W3C’s public mobile web developers mailing list public-mobile-dev@w3.org, or privately with the author at dom@w3.org.