Use Screen Size or User Agent to detect mobile devices?

I’m thinking of giving my site an alternative style sheet for mobile devices.
I plan on using PHP to determine which CSS file to link to.
Many suggest using ‘user_agent’ or ‘get_browser’ but I’m thinking of doing this by screen width instead, since some devices, such as tablets, may have sufficient resolution.
I may also add an ‘opt-out’ for anyone who wants the full-fat desk-top CSS. I suppose that would require a cookie or session for that preference.
What are opinions/advice on this from those in the know?

Just use css and media queries.:slight_smile:

Target all devices by screen width (@media screen and (max-width:1000px {} etc.)) as that is what you are really interested in - no matter what the device. ‘Device width’ doesn’t really help at all as that gives no clue to the device’s resolution.

In essence all you need to do is create a fluid layout (max-width is better than percentage width in most cases). Open and close your browser window and when the design looks bad throw in a media query and make it better. It’s as simple as that (that doesn’t mean its always easy though).

Media queries applied when the content dictates it are the way to go and then you automatically collect all devices whether you know about them or not. Chasing device widths is impossible as there are too many of them and too many variables to take into account.

The first step to advanced RWD (responsive web design) is to do nothing until something needs to be done :slight_smile:

… and don;t forget the viewport meta tag or all will be in vain.

Not a good idea - which device/browser has a useragent of “eat at joes”? It could be almost any of them since user agent is a free format user enterable field.

I was veering away from user agent in favour of screen width because it can be unreliable and there are a multitude of devices and OS out there, and not all have low res screens.

Good suggestion, but I’m not ready for that yet. I fear it would require a full redesign of my site from the ground up to make that work. It’s not in HTML5 yet, so no CSS3. I was thinking of upgrading it at some point though, when I get the time (which will be never.)
I appreiciate the concept of fluid design that works at any res, but that will have to wait until I decide, and have time for a full-on site design overhaul.
My current design is more rigid than fluid but I am happy with it and it works well on a desk top, as it was designed at the time with only that in mind. But it’s not ideal on a small phone screen and looking to the future and the rise of mobile internet, that’s maybe something not to be ignored.
To make it work on the small screen I think I need more than just CSS. I was thinking of PHP to substitute, ommit or re-arange certain elements that use too much space or over-clutter a small screen as well as loading an alternative CSS.
You may say that this gives mobile visitors a second rate experience, but I think ‘less is more’ on the small screen. For example, I have a vertical side bar which can contain various things on different pages, such as social links, a page index with links to anchor points in the page, gallery thumbs, links to sub-pages, plus some banners and widgets that fit the vertical aspect, etc… Looks good on the big screen where it’s just a small bit on the side, a fraction of the width. On the small screen it’s most of the screen width and you have to scroll down for miles to get past it to the main content (annoying). Making it narower is to narrow and makes it even longer, so it needs minimising. So I’m thinking a short horizontal top bar with less stuff in it. For example, instead of a long tall Twitter Widget news feed, just have a Twitter icon linking to our feed for anyone interested, that kind of thing which you won’t do with CSS alone, but is a breeze with PHP.
I have already started experimenting. Finding there is no way to deterine screen res via PHP was a blow, but I found and modified a bit of script that posts the info to PHP via javascript and it works. I made it so if the screen width is below a given value of pixels it sets $mobi = true; which is followed by more if statements to alter the CSS and content.
I know there are flaws, it relies on js to work, but if it works for some visitors, it is better than none, as things are now. Also having two CSS files kind of defeats the object of having a global CSS. But I’m just at the stage of finding if and how I can do this, but am now making progress.

Isn’t that where media queries come into play with a display: none ?

Html5 has nothing whatsoever to do with css3. They are completely separate and not related in any way. You can use css3 with any valid doctype. It makes no difference.:slight_smile:

That’s not always the case but it does depend on the design. However, there are always things you can do and sometimes just a few well placed media queries can transform a site quite well.

You can do that in your media query and just hide the feed and show the link. You can hide sections for smaller screen and re-arrange them to some degree (although this does depend on how you built it but some customisation is always available).

Don’t think mobile or desktop as there is no clear distinction between the two because devices range all the way up from 320px to 51" plasma screens. There are tablets that are like phones and tablets that are like portable computers and all are different sizes and different resolutions. You can’t really know where mobile starts and desktop ends. There is no mobile web - it’s just the web and you have to cater for then all as best you can.

This means not chasing devices or user agents but simply opening and closing your browser and making your design fit.

I agree its a lot easier to start from scratch but the path you are heading down is not a path that anyone else is going down and there’s a reason for that. Once you start chasing devices and making assumptions about the unknown then you are already losing the battle.

If you have a link to the site that you want to convert I could offer some concrete suggestions and indeed it may turn out that the site is so rigid that there is little that can be done but I have yet to find one that couldn’t be improved considerably.

I’m not against using media queries, but having never used them before, I possibly have not realised their potential usage, designing for moblie is something new to me. Also I didn’t see it as an option at present:

I did at first think that was the case, but whenever I have tried using new CSS3 things in the site they don’t work. However if I write some code in HTML5 and use CSS3 it does work, why is that? This led me to believe that the latest CSS only worked with the latest HTML. I must be missing something, is there some way that you declare the CSS version?
I very much like what CSS3 can do, and want to use it.
Here is a link to the site as it is, the main frame is fixed at 900px wide, so it is a rigid design.
This is a single experimental page I have been working on, by no means finished, just trying things out to see how it works. Note, if your screen is more than 2000px, it will render like the normal site, that is not the value I was planning on using, I just set it higher than my own screen so I see the mobile version on the desk top.

Give us a test case of it working with HTMl5 and it breaking without HTML5. Paul is right. You not being able to get it work is not HTMLs fault (no offense.)

As Ryan said that would have nothing to do with using html4 strict or html5 or xhtml. CSS3 will work in any browsers that supports the property you are using. Whether your css will work will depend on the browser you are using (and in older IE browsers you need a standards doctype to get proper rendering).

You don’t declare a version of css you just use it and if your browsers supports it then you are good to go. You have to make a choice on the properties you use and check browser support for the newer css3 features and then decide if you want to use them or indeed use them but supply fallbacks for older browsers. There’s no point in using some cutting edged css if its not supported by anyone but you can easily check browsers support on sites like

Here’s a timely article that explains the exact ethos of how to approach the web these days. This is something I have been saying for years and is now considered the best approach.

You can virtually change that with one line of code by setting it to max-width:900px instead of width:900px and it becomes fluid almost immediately. There will of course be alterations required but almost straight away you start to cater for mid range tablets without doing much work at all.

You should look at replacing your hover menu for a click menu because you can’t actually hover on touch devices although they do try to interpret a first tocuh like a hover but it’s just not the same and usually means you can’t close the menu anyway.

Use a click menu like this example of mine which drops down to a menu bar for smaller screens.

Then as mentioned above you can hide items in the sidebar content using media queries quite easily.

For your content I would shorten it on mobile by hiding the main content and just leaving the introduction paragraph and then add a link to show more. You can do this for all the articles on the home page to keep the display compact on a mobile. Its the same content and you just need a div around the content you want to hide and then media queries hide it on smaller screens. Just have some js ready to toggle it back on when needed.

You can scale the images smaller as required so I don’t see much of a problem there either.

Thanks for the tips guys. I have been away (from computers) this weekend, so have not had time to try things out. But I just tested sme CSS and a lot of new features do work, including media quereies.

One thing that I couldn’t get to work was HSL color. That has nothing to do with mobile friendly sites, but it is something I was trying a while back and didn’t work. That was when I made the assumption that the HTML version may affect the CSS. Another thing that shaped this assumtion was, as has been mentioned, browser compatibility. If you view the current site in FF or Chrome, you see text shadows on some elements, in IE you don’t. If I recreate a page in HTML5 and view in IE you do see shadows. Though this probably has more to do with IE being pants, rather than anything else.
Trying HSL now, it is working. I did say it was a while back, so I may have been using an older version of FF at that time.
None of this stuff is working in IE 11, so I may still need to update to HTML5 for the benefit of those unfortunate enough to be using IE. Or I could use user_agent to sniff out IE and flag up a message “Use a Decent Browser!!” (just kidding)
I will try some things out with media queries and such like then see how it goes.

Unless you give us your test cases of the code working vs not working, we cannot help you.

It is most likeley an IE thing as it does not occur in other browsers. But in IE, HTML version does seem to affect the CSS.
For example, see the existing site in IE I don’t see any shadows on the H1 or menu text.
Now view this HTML5 version of the index page in the same IE browser
Now I do see shadows.

In the head of that page you are telling all versions of IE7 and upwards to render as though they are IE7 (even IE11 and anything else in the future).

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

That means you get only the css that IE7 understood which is very little at all. You can’t blame html for that when you are explicitly telling the browser to ignore basically all of css3 and most of css2.

You don’t have a valid doctype either (as I already suggested in my previous post) so IE6 will render as though it was IE5 and will party like its 1999.

Remove the meta tag and apply a valid doctype and the shadows will return in modern versions of IE. The only IE meta tag worth adding is the edge meta tag which makes IE render in standards mode (e.g. if the browser is IE7 then it will render IE7 in standards mode. If the browser is IE11 it will render in standards mode - irrespective of whether a doctype is present or not or whether the user has clicked compatibility mode).

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Hope that explains it:)

It is starting to make sense now, removing that does help. It is something I must have overlooked, things like Doctype and some meta tags that are global to all pages are in PHP include files which I have not looked at in a while. I will have added this stuff at the very beginning of creating the site, when it was pure HTML, probably copied from some out-dated source and since forgotten how or why they are there.
One thing I’m not clear on is the doctype, as far I was aware the doctype should be valid (according to W3C), though FF page source renders it in red. What is the correct doctype for my code?
I am increasingly thinking is could be time to change everything over to HTML5 and do away with these issues.


You are using a xhtml transitional doctype in that page and transitional is a doctype that should be used while you are in transition :smile:. It is a doctype that allows certain legacy behaviours and will trigger a different rendering mode from standards mode.

These days you don’t want any of those old rendering modes so just stick to a ‘strict’ doctypes. It’s probably easier to simply use the html5 doctype anyway.

Here’s the bare bones:

<meta charset="utf-8">
<title>Untitled Document</title>


That doctype triggers standards mode in all browsers and is the easiest to remember even if you aren’t using any of the html5 new tags.

If you use that doctype then you can remove the trailing slashes from your self closing tags and you are good to go.


Use <br> and not <br /> etc..

You do have a number of validation errors in your page and of course any deprecated presentational elements won’t validate but its an easy matter to remove them (if they exist) and use css instead.

I have been having another go at re-creating the home page in HTML5 and playing with the CSS, max-width and suchlike.
I am making steady progress. I will keep tweaking it until I have a page that works any size, then start on other pages, weeding out depreciated elements and validation errors as I go.

Glad you are making progress :smile:

A progress report.
I have a new version of the homepage almost complete (still WIP), not perfect, but a big improvement I think. My intention was to make the >900px view the same as it always was, but improve things for smaller screens.
There are still a few things about it bugging me though that I have yet to work out.
There is an anoying white gap between the header image and the menu. It has actually always been there in IE, but in this new version it is in all browsers. I guess it must be some padding or margin inherited from somewhere.
I have made the menu fold in better, going from a row of 6, to 2 rows of 3, then 3 rows of 2 as width decreases. The glitch with this is just as you hit 900px the right hand menu item jumps off. I’m guessing this is due to the vertical scroller, is that right?
With the vertical side bar, I made it a horizontal top bar when the screen gets too narrow for it and slimmed down it’s content. I switched the share widget for a smaller one. I lost the easyfundraising banner (there is another at the bottom). Swapped the Twitter widget for a icon link in the ‘social’ box. I keep the Page Index as the most important element of the bar and ditched the Tide Times widget. There is one other thing in the bar which you may or may not see, depending what day you view the page, that is the ‘On This Day’ box. It is scripted to only appear on relevant days. With that I tried a show/hide method, so all you see to begin with is a title link ‘On This Day’, click it and the info appears, with a ‘Hide this’ link at the end. For this I used target in CSS rather than JS, I think it’s safe to do so these days, is it? My only issue with the bar now is the layout is maybe not the best and even with omitions it still takes a fair chunk of screen space up. I’m thinking I should maybe do show/hide for all the bar elements, so you just see links for Page Index, Social, Support Us, On This Day and Tide times. That way you miss nothing and keep it compact.
The next thing bugging me is the extra large gap above the ‘h1’ not sure whee that comes from.
Then it’s the ‘pullquote’. I made a copy of the pullquote lower in the page nearer the top for testing purposes, to see how it reacts with the sidebar. I don’t like how it clashes with it, though at least the words wrap. I did not know how to make it fit the space between the left side and the bar. Because the bar is fixed at 200px a percentage won’t do it. I tried floating but it want a bit mad.
I think I have the pictures sussed. On the site I have 2 classes for pictures. .bigpic is for large pictures centred on the page and .smallpic is for smaller pictures floated on the right. Again for testing, I made the pic of the memorial stone a ‘bigpic’. I set .smallpic img, bigpic img { max-width: 100% } so they always fit the containing div or figure. when the screen gets too narow the small pic stops floating and takes the centre like the bigpic. I’m happy with all this unless someone knows a smarter way.
The wide easyfundraising banner at the bottom now switches for the small banner, all good.
The next issue is the footer, it works but is a bit messy. The update string swaps for a shortened version,Thu Vs Thursday and Nov Vs November, OK. The issue is the height. at a certain with the date and copyright clash, so go to 2 lines. I could not get the height to adjust automaticaly so set it double in the media query, not ideal but it works.
There is still some work to do. I have not yet got a click menu, or hidden content, but all in good time. I think I’m heading in the right direction now.
When I get this homepage 100% fit I will start on the others.
Google Analytics tells me that one quarter to one third of my visitors are on mobile devices. A minority, but a growing one. I suppose a site that works well on mobile will engage and attract more mobile users. Looking at the reported screen sizes, many tablets are 900 or more, so should get the full-fat side, but I was supprised to see some desktops were below 900. The smallest screen width recorded was 320, my FF window goes down to 300 and nothing breaks, so I think I’m OK. IE squeezes down further and pops the index under the social, but how far do you take it??

Sorry for the delay in replying I must have missed this post.

It looks like you are making good and steady progress and the site is much much better now.:slight_smile: Well done.

Yes that approach is fine.

I think you must have fixed that as I can’t see a gap (unless I am looking in the wrong place)

Looks like you should set the media query to click in earlier at about 920px instead of 900px.

I prefer to do mobile menus like this (ignore the garish colours as this is just a rough example). The menu scales to fit the browser or container width without need to know about any sizes - its all fluid. As the menu begins to get squashed we swap it out for the hamburger menu which save on precious real estate in mobiles and is becoming one of the standard way to do this.

You have padding top of the h1 - is that what you mean? If so then just reduce it. Also remember that elements like h1,h2 p and ul have default top and bottom margins that you need to control.

Remove the width and set overflow:hidden to stop it sliding under the floated sidebar.

.pullquote {
    margin-left: 3%;
    overflow: hidden;
    width: auto;

Don’t set a height to start with and then you won;t need to mess with it later. Just let content dictate the height (content plus some padding top and bottom) and make sure you contain your floats so that the background wraps around the floats (add overflow:hidden to the footer to contain the floats assuming you don’t need visible overflow or use the ‘clearfix’ method). In that way you won;t need to do anything apart from perhaps unfloating the text and aligning to the center for small windows,

All in all youv’e done a very good job but the one main issue I see is that your poppy on the top is causing a horizontal scrollbar at nearly all but the widest views. The reason is because it overhangs the layout and causes the scrollbar to appear before its needed. This will cause you problems all the way down as mobile views will increase the width to accommodate this poppy resulting in the rest of the content being shortened and not reaching full width. You can’t afford to have a horizontal scrollbar on mobiles as that cause all sorts of issues with content size.

You have a couple of choices.

  1. Make sure the poppy does not hang outside the layout edge or at least make sure that on screen widths less than the layout width + poppy overhang you change for an image that does not overhang.

  2. Us this complicated method to achieve that effect.

I usually set 300px as my limit as most new devices are above that and there are few 240px devices around and although the design may not look right on those smaller devices they should still be usable.