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.
Copy & paste the code below to embed this comment.
Jordan Gray
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.
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.
…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.
Copy & paste the code below to embed this comment.
Benjamin Hawkes-Lewis
“Nuovo Labs”:http://nuovolabs.com/ suggest:
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.
Copy & paste the code below to embed this comment.
Adam Davis
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.
Copy & paste the code below to embed this comment.
Jordan Gray
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 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 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+xmlMIME-type, which is recommended for use with this particular document type. (I believe it renders it as straight application/xhtml+xml, which Firefox supports.)
Copy & paste the code below to embed this comment.
Dominique Hazaël-Massieux
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.
<!—[if IE]><link href=“screen.css” rel=“stylesheet” type=“text/css” media=“Screen” /><![endif]—>
<link href=“mobile.css” rel=“stylesheet” type=“text/css” media=“handheld, only screen and (max-device-width: 480px)” />
<link href=“screen.css” rel=“stylesheet” type=“text/css” media=“screen and (min-device-width: 481px)” />
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.
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.
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:
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
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.
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.
Copy & paste the code below to embed this comment.
ralat
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
36 Reader Comments
Back to the ArticleHarnish Goradia
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?
Jonny Schneider
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.
Jordan Gray
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.
Nathan de Vries
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.
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.
Brian King
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
Benjamin Hawkes-Lewis
“Nuovo Labs”:http://nuovolabs.com/ suggest:
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.
David Kees
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.
Adam Davis
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.
Jordan Gray
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 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 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+xmlMIME-type, which is recommended for use with this particular document type. (I believe it renders it as straightapplication/xhtml+xml, which Firefox supports.)Dominique Hazaël-Massieux
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:
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…
Dean Hamack
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.
<!—[if IE]><link href=“screen.css” rel=“stylesheet” type=“text/css” media=“Screen” /><![endif]—>
<link href=“mobile.css” rel=“stylesheet” type=“text/css” media=“handheld, only screen and (max-device-width: 480px)” />
<link href=“screen.css” rel=“stylesheet” type=“text/css” media=“screen and (min-device-width: 481px)” />
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.
JK Wen
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.
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.
David Storey
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.
carla san gaspar
Well the only problem that i can see here is the utilization of the CSS…
Harnish Goradia
This is a great post given how connected mobile devices are proliferating and are increasingly used to consumer web content.
bruce lawson
I’m a little confused, Dominique. The article mentions IE7 mobile and IE 8 mobile, but the latest version of IE mobile is 6.
Justen Robertson
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.
garteth coyle
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
Dean Hamack
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/
sanjeev singh
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
22websitedesign
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
bennee
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
nickw108
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.
Tim Sookram
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.
ralat
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?
webtimal
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