Return of the Mobile Stylesheet

35 Reader Comments

1. 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?

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. What about letting the handheld stylesheet 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 change handheld to screen depending 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?

10. 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.

11. 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?

12. 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.

13. 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.

14. 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.

15. 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

16. “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.

17. 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.

18. 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.

19. 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.)

20. 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…

21. 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.

22. 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.

23. 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.

24. This is a great post given how connected mobile devices are proliferating and are increasingly used to consumer web content.

25. I’m a little confused, Dominique. The article mentions IE7 mobile and IE 8 mobile, but the latest version of IE mobile is 6.

26. 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.

27. 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

28. 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/

29. 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

30. 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

31. 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

32. 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.

33. 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.

34. 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?

35. 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