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.
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
handheldstyle sheet. - Some read only the
handheldstyle sheet if there is one, but default to thescreenstyle sheet otherwise. - Some read both the
handheldstyle sheet and thescreenstyle sheet. - Some read only the
screenstyle 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.
|
CSS Behavior |
Browsers |
|---|---|
|
Reading only |
OpenWave browser, Nokia lite-web browsers, Netfront (configuration dependent), Digia, BlackBerry browser, Opera Mini until v4, Opera Mobile until v9 |
|
Reading both |
Palm’s Blazer, Nokia S40 browser, IEMobile 6.x and 8.x |
|
Reading only |
iPhone’s Safari, Opera Mobile starting v9, Opera Mini starting v4 |
|
Reading only |
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:
floatanddisplay: because these properties are traditionally used to create multi-column layouts, they tend to require mobile users to scroll or zoom,paddingandmargin: since screen real estate is limited on mobile devices, you will want to reduce or remove most of these on mobile screens, andbackground-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.cssfor PC browsers, - define a style sheet
antiscreen.cssto cancel any non-mobile friendly effects set inscreen.css, - tie these two style sheets together into a
core.cssstyle sheet, à la:@import url("screen.css"); @import url("antiscreen.css") handheld; @import url("antiscreen.css") only screen and (max-device-width:480px); - define a style sheet
handheld.csswith 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
@mediablocks or@importdirectives).
|
CSS Behavior |
|
|
|
|
Result |
|---|---|---|---|---|---|
|
PC Browsers |
read |
read |
not read |
not read |
|
|
Reading only |
not read |
not read |
not read |
read |
|
|
Reading both |
read |
read |
read |
read |
|
|
Reading only |
read |
read |
read |
read |
|
|
Reading only |
read |
read |
not read |
not read |
|
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
handheldstyle 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
handheldstyle sheet when they request thescreenone.
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
antiscreentechnique (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 [email protected], or privately with the author at [email protected].
Useful discussion on something I have been thinking about for a while now.
What are your feelings on the need to go beyond just changing the stylesheet and actually altering the content and basic structure of the mobile version of the website?
So essentially removing all non-key content and having the most important features at the very top of the page, to avoid scrolling all-together.
Also what about putting this mobile edition of the website on a separate sub-domain?
Hi David,
The more you can adapt a site to mobility, the more likely the user experience will be improved – adapting the style sheet is indeed only a first step, and altering the content and structure is likely going to be required if you want the best user experience possible.
Regarding a separate sub-domain: if you can avoid it, it probably is better – your users and search engines already know the existing addresses of your content, and creating a whole new addresses space reduce that value.
Mobile browsing doesn’t just suffer from poor CSS compatibility. The experience is inferior by definition due to small screen size (even the iPhone doesn’t match a 22″ LCD), no keyboard or mouse, and generally a totally different experience.
People use it when the information or functionality they need cannot wait until they are at a computer screen – up-to-date news, sports results, maps, quick reference, etc.
Hence, to take advantage of mobile traffic means more than adjusting your CSS, but considering your HTML, content, navigation, and general functionality. For the vast majority of sites, the effort required is simply not worth it.
I read through your article nodding my head, thinking “wouldn’t that be nice?” Sadly, I don’t think it’s at all realistic.
Going from the web to the mobile is a pretty harrowing experience. In the beginning you try to provide “correct” web-inspired solutions to everything, but it’s not long before you realise that bringing best practices from the web to the mobile just isn’t possible.
You will need a separate website for mobile users. You will need to use tables for layout, font tags to colour text, HRs to divide content, and proprietary attributes to switch text-input modes and allow key based navigation. You will need to do not only user agent detection, but also capability detection using WURFL and/or DeviceAtlas to find out the size of the screen you’re dealing with, or perhaps to check if the device supports file uploading or sms:// linking. You will even discover devices that POST when told to GET, and GET when told to POST.
It’s easy to think that the iPhone and other recent non XHTML-MP devices have changed things overnight, but that’s most certainly not the case. If you want to support even just a handful of the most-used handsets, you’re in for a bumpy ride.
I’ve heard many people say or write that the only way you can reach users on mobile devices is to do full content-adaptation; while I think it is one of the options you need to consider (in particular if you expect a good RoI from mobile users), I fail to see why not going that far is not useful at all; I’m a heavy mobile-web user, and while I would probably rate higher web sites that are fully customized for a mobile experience, I do rate much higher sites that have made some simple efforts to be mobile-friendly than sites that haven’t.
I think my number one gripe with web sites on mobile devices is the scrolling/zooming problem – CSS can solve that one fairly cheaply without having everybody rolling up a completely separate mobile version of their site, so I don’t think we should ignore that option.
The anti-screen technique does seem like a fairly simple step to improve the mobile user experience. I wonder if it wouldn’t be easier for some sites to turn off css rendering? Is that possible? I have always felt like that a major benefit to designing with web standards is “design once, publish everywhere”. With semantic markup the more important information should be at the top of the page anyways and with css turned off and taking advantage of accessibility techniques mobile users could get their information quickly without much scrolling, although not as pretty.
You’ll note that some browsers (Blazer, the default browser for Palm, for instance) will interpret both the screen and handheld css. I did some testing on this last year and found that Blazer actually interprets ALL css, including print. It’s logic is to interpret them as part of the cascade, i.e. in order.
I must note that I completely disagree with Nathan who (above) stated “You will need a separate website for mobile users. You will need to use tables for layout, font tags to colour text, HRs to divide content, and proprietary attributes to switch text-input modes and allow key based navigation”.
I’ve not found that to be the case in my testing of common web site markup and coding on the more popular consumer mobile browsers (Safari, Blazer, Opera, IE). It sounds like Nathan may be referring in an unspecified context to uncommon browsers, devices, or web applications.
I haven’t designed for mobile devices much in the past, so I will be the first to admit that I’m no expert on the matter. But it would seem to me that there would also be a substantial benefit in keeping the same site design as the one people encounter via their computers.
It is likely that people get comfortable with a layout on a computer’s browser first. Being the “native” or “original” design, it is almost always exactly as the designer intended. Learning a site’s structure is an important element of usability as well. So if they learned on a computer, why not mimic the experience they already have stored in their memory when they visit via a mobile device?
There should definitely be an effort to make sure the site is very usable regardless. Eliminating horizontal scrolling as much as possible, etc.
But should we ever change the fundamental nature of a site’s navigation to be more suited for mobile devices if that undermines the users original experience via a computer?
I’m not so sure.
What about letting the
handheldstylesheet cascade the default layout styles (like ALAs print style does for printing)?Add
only screen and (max-device width:480px)to the second and/or use Javascript to changehandheldtoscreendepending on browser width.Now both basic browsers (ignoring media attributes) and more advanced browsers (supporting Media Query or Javascript) get the handheld styles.
Creating and maintaining a consistent style across both desktop and mobile would be much easier, because the same basic styles are used (in this example from
default.css).This wouldn’t be a bad thing, is it?
Using a different CSS doc for your mobile version is one way to do it of course. It’s common to see parts of a design disappear in a mobile version, and through CSS the only way is to hide it. This is not smart because what will happen when screen readers come with the IPhone is that the screen reader will read all of the content, even if you’re hiding parts of it, and things won’t make sense to the non-visual audience.
Would anyone know if I wanted to just write a style sheet for only an iPhone or the Storm how would I set it up in the header?
I agree with most of the criticism on this approach which implies that this is no replacement for a mobile specific solution. Clearly Dominique does too
bq. although a mobile-specific user experience will serve your users’ needs better, a mobile-friendly website is better than nothing.
We all know that no amount of CSS hackery will address the users context and need i.e. by presenting your largescreen site in a better way for smallscreen, you won’t make people need it or want it on smallscreen.
However, Dominique’s solution does offer one way to _improve_ your site for mobile devices if you had some kind of reason to do so, but not so much a reason to invest in a real solution.
So a logical first step would be proper analysis of user needs before entertaining such ideas as reorganising your content and targeting mobile device with additional CSS. If it really is _that_ critical to get your content to mobile users, then you probably should have mobile specific version – it’ll be better for you, and your users.
As someone who has developed a couple of online services targeted specifically at mobiles (I work as the web developer for a mobile phone recycling company), a rather more reliable alternative than user-agent sniffing is to check the HTTP Accept header to see if a device accepts certain common MIME-types which are specific to mobiles. For example, XHTML Mobile Profile and WML should only be accepted by mobile browsers; this is one of the techniques Google uses to determine what content it should serve up.
I have collected a more comprehensive list of resources at work for individuals developing web sites for mobile devices, especially Nokia phones, which I will supply tomorrow for the benefit of interested parties.
bq. It sounds like Nathan may be referring in an unspecified context to uncommon browsers, devices, or web applications.
Certainly not “uncommon” at all. We’re talking about average phones here…phones that non-early adopter folks carry with them every day in their pocket. If you think most phones are running Webkit or Fennec, I guess that’s where our difference of opinion lies.
But you are right, I’m talking about mobile applications as opposed to sites wanting to expose non-mobile focused content. Regardless, I’m still certain that providing mobile content is not as simple as linking in a different stylesheet, just the same as I’m certain that building a website is not as simple as hitting “export as HTML” in Microsoft Word. Your mileage may vary.
bq. …a rather more reliable alternative than user-agent sniffing is to check the HTTP Accept header
I’d love to see some data on this, because in my experience it’s one of the least successful ways of detecting mobile user agents.
As with web browsers, why expect a one-size fits all mentality.. it wont and never will.
Designers need to target a % market and encourage the market to follow..
Mr Melbourne
“Nuovo Labs”:http://nuovolabs.com/ suggest:
bq. This is not smart because what will happen when screen readers come with the IPhone is that the screen reader will read all of the content, even if you’re hiding parts of it, and things won’t make sense to the non-visual audience.
In the worst case scenario, where the content is rendered by the mobile screen reader, why would it make any less sense than the same content rendered by a desktop screen reader?
I think it’s more likely that the content would not be rendered by the mobile screen reader. On the desktop, VoiceOver does not read content in Safari with display: none; set. (Note that popular screen readers only pay attention to the screen media type, and that the display property applies to all media types.) I don’t have a phone with “Talks”:http://www.nuance.com/talks/ or anything to experiment with, however.
Unless there’s a difference between mobile screen readers and non-mobile ones, using CSS to _*display: none*_ should keep the content from being read. What worries me about this is the serving of the content to the mobile device still occurs, so that massive image that loads snappily on your PC with its T1 connection would still be served to the mobile device regardless of whether or not it’s going to be displayed.
What would be nice is a server side solution that we could utilize to specifically serve the appropriate content to mobile devices but, as noted above, this could be prohibitive for many organizations.
Using the approach described in the article will result in some handheld browsers loading both antiscreen.css and handheld.css. What is the advantage of having 2 CSS files in these cases?
Maybe I’m missing someting, but it seems to me that everything that would go in antiscreen.css would normally go into handheld.css.
As I promised: an excellent and fairly comprehensive reference is “mobile-phone-specs.com”:http://www.mobile-phone-specs.com/. “WURFL”:http://wurfl.sourceforge.net/ also provides a wealth of information about mobile capabilities in a downloadable XML() format. Both include known user agent strings for each model.
There are a number of Firefox extensions that have proved invaluable to me, and might be useful for other developers. For example, “wmlbrowser”:http://wmlbrowser.mozdev.org/ allows Firefox to display WML(Wireless markup language) pages. This extension is especially useful in conjunction with “wmbpviewer”:https://addons.mozilla.org/en-US/firefox/addon/8345, an experimental addon which provides support for WBMP(Wireless bitmap format) images, and the “small screen renderer”:https://addons.mozilla.org/en-US/firefox/addon/526.
I’ve occasionally used the “user agent switcher extension”:https://addons.mozilla.org/en-US/firefox/addon/59 too, and also “tamper data”:https://addons.mozilla.org/en-US/firefox/addon/966 to mess around with request headers(e.g. HTTP() Accept). Finally, the “XHTML() Mobile Profile extension”:https://addons.mozilla.org/en-US/firefox/addon/1345 adds support for the @application/vnd.wap.xhtml+xml@ MIME()-type, which is recommended for use with this particular document type. (I believe it renders it as straight @application/xhtml+xml@, which Firefox supports.)
Yes, having the mobile rules in antiscreen.css rather than in handheld.css would work as well, but you need to ensure that antiscreen.css becomes visible to those devices that support only handheld style sheets – just a bit of tweaking, really.
The advantages of keeping them separate are:
* maintenance: antiscreen.css is supposed to focus only on canceling screen.css
* the browsers that only get the handheld style sheets won’t have to download the content that isn’t useful to them
But clearly these are relatively small advantages, and depending on the population of mobile devices that visit your sites may not be worth the cost of an extra request for the browsers that will download antiscreen.css…
I agree with a couple of the other posters, this is overkill. I’ve been using the following for several months now and it works on iPhones, iPod Touch, G1, Blackberry, and N95. Sadly, my mobile styles aren’t picked up by Windows Mobile, but neither are the screen styles, so those users just get a barebones page. But if you use good coding practices, that’s usually good enough.
Note the capital “S” in the IE conditional block. That’s a weird little hack I picked up that prevents Windows Mobile from picking up the screen styles.
Chris Meeks wrote above: “it would seem to me that there would also be a substantial benefit in keeping the same site design as the one people encounter via their computers.”
I agree. For my web site layout, here are the things that I watched for.
* Content flow / layout is consistent with or without style sheet
* Minimal horizontal scrolling
* Minimal nav at the top of page
I found them to still give me enough flexibility to design the layout for non-mobile screen to my liking – with the added benefit that it looks consistently on a mobile phone screen. (I tested mine with Nokia 6230’s tiny screen running Opera Mini.)
If this works for your web site style and content (it requires rethinking of your assumptions), then it means you only need to maintain one set up for both mobile and regular access. The benefit is not just in maintenance effort, but also single point of entry for your audience.
A few comments:
The example media query uses 480px. This is exactly the iPhone screen size if I’m not mistaken. I’d prefer not to promote this as many mobile devices are already out with much higher resolution screens than the iPhone, but smaller physical dimensions. An example would be the HTC Touch Diamond, which we (Opera) are the default browser, or most Japanese phones.
The issue with the approach in this article is that the mobile browser has to do more work. It (if it is a modern mobile browser) will render the screen, antiscreen and handheld.css stylesheets. This requires more processing, more bandwidth and more HTTP requests, which will add more latency. Ideally we’d want the opposite as the user may be paying per kb, and phones have limited processor, memory and battery life. According to Yahoo! research, IE is also slow on @import rules.
Ideally, we’d want to use max-device-width (in combination with a plain handheld media type) for mobile browsers, and min-device-width for regular PC browsers. The issue we have found (and I think you found the same issue) is that IE will render no styles if a media query is added, which is against spec (i.e, browsers should render “screen and (min-device-width: 25cm;)” even if they understand nothing after the “and” conversely “handheld, only screen and (max-device-width: 25cm;)” should be used for mobile and none Media Query aware browsers would not understand the “only” keyword and not render it). The same issue also affects Safari 2 and below. This was a big problem when we were experimenting, but it maybe that we can ignore Safari 2 now, and can solve IE with a conditional comment. The Opera web site does some browser sniffing to fix known broken browsers – not ideal but we didn’t see an ideal solution otherwise.
We also thought about this solution, but we decided against it due to the issues above and the maintaince issue mentioned in this article. For a trivial site it isn’t a problem, but if you have multiple developers working on a site and the stylesheets often get updated, there will be a time when the mobile version breaks due to the new styles not being overridden, and the mobile stylesheet will get very long working around every new thing that we don’t want displayed on mobile. This is exagerated if the site accepts user generated content.
Interestingly when we did some research on handheld single column mode vs. zoom based interface, the later was preferred as the users recognised the site in question. This will likely only extend to sites that the user is familiar with, and countries where they are used to desktop browsing. In places like Africa and China, many people’s first Web experience will be on mobile. If they first use mobile view, it is possibly likely that they’d prefer that method as there is no panning and zooming to read content.
It is often stated that there are hundreds of mobile browsers and developers can’t rely on CSS etc. due to these basic browsers not having the capabilities. I generally find this is not an issue [disclaimer, I work for Opera] as these browsers often ship on many phones but the usage is not significant. As the user experience is not high enough, the user either doesn’t use the web or downloads a different browser. Opera Mini and Mobile and Safari on iPhone/Pod have taken off as they provide a good user experience and they support regular web sites the user wants to visit (for the most part), even if that site isn’t designed for mobile.
On the subject of mobilisation, rather than adapting for small screen. It isn’t that cut and dry. Our users generally prefer the desktop version rather than the specific mobile version of a site, especially judging by the bug reports we get when a top site redirects Opera mini to the mobile version, and the types of sites in our top site list for the Opera Mini servers. This is because the developer has assumed what they’d want when mobile, in the mobile context, and that assumption is often wrong, as different users want different things, and I’d guess most sites don’t do user research to find out. There is also no reason why PC users wouldn’t want the location based information that mobilised sites often give. A laptop user often is using the browser while mobile (cafe, travelling, etc.) and netbook usage is taking off. The small size of these means they are increasingly used on the move.
For the adaption of the stylesheet to mobile, while the technique here is good, I prefer the duel media query approach I highlighted (and a cc for IE), especially if we can convince someone on the IE team to fix their media type parsing bug. Using a physical screen size rather than px would be better but I’m not sure how different browsers handle that yet, or what size is the ideal size as a cut off point.
This is a great post given how connected mobile devices are proliferating and are increasingly used to consumer web content.
I’m a little confused, Dominique. The article mentions IE7 mobile and IE 8 mobile, but the latest version of IE mobile is 6.
Using the mod_rewrite method, a better approach is to enumerate the browsers you want to deliver a screen stylesheet and default to the handheld. Only the major desktop browsers need be supported this way; all the mobile browsers will get the mobile stylesheet whether their developer likes it or not, and you don’t need to add a new device to the list every time one comes out, whereas new desktop browsers are released infrequently.
They are already working on foldable screens for mobile device which im sure will catch on. So you ipod will fold out to a screen twice the size – or bigger. So it may not even be necessary to have a special version of your site. people would be very comfortable holding a foldable screen the size of an open book while travelling by bus or sitting in a cafe.
http://www.webdesignwicklow.ie
I tested this method throughly and it fails on a pretty large number of browsers including Symbian and Mobile IE. If you want to read about a better method I’ve developed that works on at least 80% of the mobile devices out there and uses only two stylesheets, read my article on the subject here:
http://www.bushidodesigns.net/blog/mobile-device-detection-css-without-user-agent/
it’s crucial to be well-informed about modern and future web standards. To help you stay ahead of the curve – here are 20 excellent resources on the topic of CSS3 at http://webusabilityhelp.blogspot.com/2009/03/20-useful-resources-for-learning-about.html
Hi,
mobile style sheet working but if it is heavy then how we can optimize CSS for mobile sites.. is there any technique for optimization mobile website… I want to make mobile website
Your article was really good, thanks would implement for http://www.awoof.org, I viewed this site using BOLT and it showed the entire page (using the screen css), hopefully I should make the site shed some ‘mobile weight’ after implementing your css ideas.
Cheers
It seems that the “only” does not work.
Instead of
<link rel=”stylesheet” href=”handheld.css”
media=”only screen and (max-device width:480px)”/>
it needs to be
<link rel=”stylesheet” href=”handheld.css”
media=”screen and (max-device width:480px)”/>
to apply the stylesheet correctly on my iPod.
Opera Mini seems to have trouble with the “only” keyword in the media declaration. If you look at David Story’s example here: http://my.opera.com/dstorey/blog/media-queries-and-handheld-stylesheets
He’s using media=”handheld and (max-device-width: 480px), screen and (max-device-width: 480px)”
Technically he’s using the @media{} inside the stylesheet, but I found it was actually the “only” keyword that was stopping opera mini from reading my stylesheets and you can use <link> if you’re more comfortable with that method.
I wonder how this works for the iPhone 4, which has a 960 × 640 resolution. You could use the only-rule with width:960px, but that means that all screens with a lower width will use this stylesheet. What is the best way to handle this?
To convert an existing website into its mobile version is a different task than the PC version designing. Different resolutions, different OS, different browsers will make it tough for a designer/developer. Â Different style sheets for PC and Hand Held devices are a nice idea. Â We need to take extra effort to make the website visually appealing and user friendly in hand held devices. Mainly we need to focus on the following things.
1. Fix the website to the smaller resolution
2. User friendly Structure
3. Easy Navigation