Resolution dependent layout

21 September 2004

53 comments

A Blue Perspective: Resolution dependent layout

» Varying layout according to browser width «

Updated: 19 January 2006 (See the new entry for details)

A few weeks ago I thought that I might try out 1280 x 960. 1024 wasn't really doing my 19" any justice and I thought that if I cranked it up I might actually be able to design a full web page in Photoshop without having to squeeze between palettes and grope at scrollbars.

Boy, was it luxurious – way more content on screen, smoother edges, and plenty more squinting. But after I'd put out my first design at super-res and looked at it on another system, I had to swap back. Why? Because there was too much freedom for me. With so much space available – particularly in my browser – it was too tempting to use it, and people from the year 1998 be dammned!

I've said it before: Web design is about working well within restrictions. This often means catering for the lowest common denominator. Nowadays, in the case of page layout, this means making sure your site doesn't have horizontal scrollbars on a maximised 800 x 600 screen. That's 25% more than the baseline of six years ago – 640 x 480. Who knows what it will be in 10 years?

The nature of technology is change; better, faster, stronger. The challenge for those who design applications that rely on technology is to provide forward-thinking design while still allowing those with outmoded technology to access the new applications.

Speaking entirely visually, there's quite a few technologies in flux at the moment that affect web design – font support, CSS 1/2/3, Standards support, SVG – but I would consider most of these to be efficiency gains; they don't affect what we do, so much as how we do it. Monitor resolution, however, I think has the capability to affect the fundamental design of web pages.

A good example is the new(ish) Coudal site. Designed specifically for 1024 or greater, its layout is something that just wouldn't work on 800. Three columns begins to look a bit cramped at that width, and even though it might be readable, it certainly wouldn't be the pretty image that Coudal would like to convey, so they've left 800 x 600 by the wayside.

Of course, this probably isn't viable in a commercial setting (depending upon your target market). That is why, on a soon to be released web project, I've utilised the inherent separation of content and style in XHTML/CSS to allow for two distinct layouts. One for 800 and below, one for above.

It's essentially a news site, so the homepage – with its snippets of articles and pictures – is a prime candidate for columnification. But you don't get too many words per line at squishy widths, so at lower resolutions it's better to present the user with a single column of teasers. Of course, it all has to be degradeable.

The solution is to add a little vitamin J. JavaScript can tell you what the width of a browser is, then react accordingly. By default the content is displayed in a single column. Non-JavaScript enabled browsers, or lower resolution ones, will stay that way. But if you're 1024-up, with JavaScript, an alternate stylesheet gets put into action. See a simple example here. I'd like to see tables do that.

Granted, it is extra work (the scale of which depends on the complexity of your design), but when it improves the overall usability, readability and browseability of your site without leaving anyone behind, it can be a worthwhile investment.

Tested in IE6, Firefox 0.8, Opera 7.5. IE5.x (Win) receives single column layout by default, as support for % widths is buggy.

Categories

, , , ,

Comments

  1. 1/53

    Filosof commented on 21 September 2004 @ 03:27

    I had the same problem on a few websites..

    thx you.

  2. 2/53

    Jeff Minard commented on 21 September 2004 @ 03:49

    That's pretty awesome actually. Good idea and execution :D

  3. 3/53

    Coudal commented on 21 September 2004 @ 07:17

    Nice, we might have to install something like that. We debated the dimesions of our new-ish design quite a bit. The funny thing is, while we've had a lot of email about this and that feature we haven't had a single person write to say it's too wide. Fwiw: Our stats showed less than 4% using 800x600 before we switched and about the same now.

  4. 4/53

    Jason Berry commented on 21 September 2004 @ 10:58

    You swapped back to 1024 on a 19"? Ewww.

    Why not just resize your browser to 800x600 using Firefox's web developer toolbar to test sites on 800x600, or 1024x768 for that matter?

    Things are so much easier at 1280... Try 1280x1024. It's what I run all my 19" monitors at. Makes thing so much easier designing as well as you can push the palette's off your actual workspace... nice =)

    So, instead of dropping to a dodgy resolution, resize your documents =) Switch to the lower resolutions for testing!

  5. 5/53

    Nick Cowie commented on 21 September 2004 @ 12:41

    Been doing something similar for a while, using an elastic design (ems for page container, column widths, font-size and everything else I can manage ) and using javascript to change base font size depending on browser window width.

    900px pixels or less (or no js) gets a well formed smaller version, that looks good at 800 by 600. (font-size=69% aka 1em=11px)

    901 to 1100px, get the the regular and perfectly formed version. (font-size=81% aka 1em=13px)

    1101px and above, get the super sized ;-) version that looks good on certain colleagues browsers. (font-size=94% aka 1em=13px)

    Got to make sure background images work with all sizes, but otherwise probably a little less work than Cameron's option.

  6. 6/53

    Nick Finck commented on 21 September 2004 @ 13:18

    Well done! This is a perfect example of using the behavior layer and presentation layer the way they were intended to be used.

  7. 7/53

    The Man in Blue commented on 21 September 2004 @ 14:43

    Nick C: yes, elastic designs are an option for differing resolutions, but they merely resize the same layout into a larger space. They don't address the fact that at larger resolutions you have the ability to offer an entirely different experience.

    Although I've previously experimented with elastic solutions:

    http://www.themaninblue.com/writing/perspective/2003/12/22/

    I'm now wondering about their usefulness. Given that there should be a correlation between resolution and physical monitor size (e.g. 15" = 800 x 600, 17" = 1024 x 768, 19" = 1280 x 960) I'm given to thinking that increasing the font size would just make the fonts bigger (and perhaps uglier), without improving the experience.

  8. 8/53

    Keith commented on 21 September 2004 @ 15:12

    Wow. Pretty cool idea that. Nice work, definitely worth bookmarking and keeping in the bag of tricks.

  9. 9/53

    Meitar Moscovitz commented on 21 September 2004 @ 16:21

    Wow. That's really utterly perfect. Great job; thanks for this post!

  10. 10/53

    Mark Tranchant commented on 21 September 2004 @ 17:12

    Nick C: Sometimes, the reason that people run lower resolutions is to make the default OS fonts and widgets visible. My parents run 800x600 on a 17" monitor for that very reason. Your system would compensate for them doing that, and feed them smaller fonts than they want. Sure, they can resize, but then pop goes your layout unless you've done it properly.

  11. 11/53

    Richard@Home commented on 21 September 2004 @ 18:46

    What a cool piece of code :-)

  12. 12/53

    Nick Cowie commented on 21 September 2004 @ 19:09

    Cameron wrote:
    >I've previously experimented with elastic solutions:
    I knew I "borrowed" some of it from somewhere, now I know. The main problem is how ugly H1, H2, H3 and H4 tags where looking at some combinations. But know I have sIFR:
    http://www.mikeindustries.com/blog/archive/2004/09/sifr-2.0b2-mo-betta-beta
    to resolved that issue.

    Mark T: I know different people run large monitors at low resolutions, ie a 21" at 800 by 600.

    If you view an elastic site with font size dependent on browser width is that the fonts and most design elements will look roughly the same size on a 17" monitor at 800x600, 1024x768 and 1280x960. So your parents and others are not being denied or restricted. They get the same site.

    If somebody has set there font size to large ieverything will be larger and not fit in a single window, but that is the price to be paid.

  13. 13/53

    Jon Hicks commented on 21 September 2004 @ 19:12

    I've been trying to work out how to do this for ages!

  14. 14/53

    Brad commented on 21 September 2004 @ 20:21

    (Cameron, you're an Aussie so you'll appreciate this)

    Commercial example: (2 Fairfax newspapers, to be exact)

    The Sydney Morning Herald [1] and The Age [2] sites (both semi-newly upgraded to CSS layout) use a similar trick. I personally appreciate this effort, because browsing a broadsheet style design on the net is a pain in the ass if you're restricted to 800x600.

    However, unlike yourself, they use a Document.Write trick when the page loads. I prefer the elegance of your method.

    [1] http://www.smh.com.au/
    [2] http://www.theage.com.au/

  15. 15/53

    Ron Selling commented on 21 September 2004 @ 21:12

    Opening the site in IE 6.0.2800.1106 and *kaboom*... JavaScript error at line 32 (
    <body onload="init();">).

    Still, I would consider giving it a 2nd try.

  16. 16/53

    The Man in Blue commented on 21 September 2004 @ 21:49

    Uhhh.... yeah :o]

    Forgot to take that function out of the template when I ported the code over. Fixed now!

    The code is actually activated by a late late script call at the end of the HTML, so it affects the content as early as possible. But onload is always an alternative. (I find it takes too long to activate, though)

  17. 17/53

    Alan P. commented on 22 September 2004 @ 02:05

    As always well thought out and well documented Cameron. I have to say though, I think the suitability is limited due to the delay in rendering and the subsequent "jump" in the layout. (I suspect that this becomes more pronounced the heavier the page._

    Just a further note on Win IE5.x : at >800px it thinks it's in 3 col mode and turns off the background colour - shame.

    Alan. (regular lurker)

    ps: drat - you've got the Top Cat theme tune stuck in my head now!

  18. 18/53

    Roger Johansson commented on 22 September 2004 @ 02:37

    Nice! Hmm. What if you combine this with min-width and max-width... even better :)

  19. 19/53

    Andrew commented on 22 September 2004 @ 03:23

    Cameron, when you create examples like this, it would be helpful if you could just put all the relevent CSS and JS in the example.htm document itself, rather than linking to external files. It's much easier to dissect that way.

  20. 20/53

    chris holland commented on 22 September 2004 @ 03:44

    Eh! I just thought i'd chime-in to mention it works beautifully in OS X's Safari :)

    Congrats :)

  21. 21/53

    Darrel commented on 22 September 2004 @ 04:27

    This is a very ingenious solution. Nicely done!

    That said, I'd like to point out something that seems to be taken as common sense in these comments...that screen resolution equates to browser size.

    It doesn't. Screen resolution has nothing to do with the size of the user's browser's viewport. They are independent variables that do not have a direct correlation.

    Yes, more people, at least on the desktop computer, are using larger monitors. But not everyone maximizes their browser. Not everyone hides their bookmarks pane. Not everyone hides their history pane. In fact, some folks use bigger monitors so they can have more, smaller windows open at one time.

    So, again, great solution, but let's not forget that screen resolution is often a red herring when speaking of 'how big' to design your page.

  22. 22/53

    Philipp Lenssen commented on 22 September 2004 @ 04:45

    Not to disillusion anyone, but as far as I know you can't detect the window width with JavaScript. You can only figure out the screen resolution. Even then I'd rather wait until the minwidh/ maxwidth CSS properties are implemented cross-browser than mixing JS and CSS. This page is a good example for a technically interesting fluid layout, which however runs into the old problem of line-length -- it's just too wide on my screen. As for the font-resizing, I can do that already with a short-cut that works on any site, and I don't really need any other buttons. Still, kudos for this layout which looks good.

  23. 23/53

    Philipp Lenssen commented on 22 September 2004 @ 04:47

    I checked the demo and it does seem to dynamically get my browser width. Looks nice :)

  24. 24/53

    Ben commented on 22 September 2004 @ 05:07

    Could this perhaps be simplified even further (or interestingly used in conjunction) with javascript functions inside the CSS, like the mimicking of the max-width in CSS (width:expression(document.body.clientWidth>800?"800px":"auto"))?

  25. 25/53

    kenji commented on 22 September 2004 @ 06:39

    the (absolutely essential) web developer toolbar for moz/firefox has a series of nice functions for resizing your window at 800x600, 1024x768, etc resolutions. it also will tell you what size you have your current window open at.

    http://www.chrispederick.com/work/firefox/webdeveloper/

    at any rate, it seems like this article's method could be enhanced with a bit of css min-width. on the sample page, for example, when you make the screen really small, the top navigation starts to bleed below its boundaries. if you add sufficient min-width to the body, the browser will stop floating elements into each other and just throw up a scrollbar.

  26. 26/53

    Sandy McArthur commented on 22 September 2004 @ 07:20

    Why not simply change the class of the body tag to be "normal" or "wide" instead of (de)activating linked stylesheets? Then you simply make your CSS selectors be something like:

    body.wide .col3 .feature {
    ....
    }

    Also, this way wouldn't interfere with Mozilla's user style sheet selector option in the event the user does resize the window.

  27. 27/53

    Richard Hulse commented on 22 September 2004 @ 07:29

    We do something similar on our programme schedule pages but the JS is not so elegant. And only for the IE browser.

    If the browser is too narrow then the floating day selector changes to visible list above each day

    http://www.radionz.co.nz/index.php?section=schedule

    and go to a schedule page.

    thanks for your solution.

  28. 28/53

    Mike Steinbaugh commented on 22 September 2004 @ 09:29

    Funny you mention this new technique, since I implemented it on <a href="http://webspiffy.com/">Webspiffy</a> a few months ago. The resolution swap is pretty subtle on the site. At lower resolutions, the logo moves to the top of the page and the content centers in the browser. At larger resolution, the logo moves to the left, and the page forms a digital business card. The larger the screen setting, the more content you see too.

  29. 29/53

    The Man in Blue commented on 22 September 2004 @ 12:43

    Alan (comment 17): I think that the "jump" can be eliminated by including the detection in the head of the document. The reason that I place it at the end of the HTML document is because I actually affect the height of some of the elements and they need to be rendered in order to do so. But, if you are doing a pure stylesheet switch then it can probably be done in the head.

    Sandy (comment 26): I prefer to use alternate stylesheets so that they are also accessible via the browser.

  30. 30/53

    Mark Tranchant commented on 22 September 2004 @ 19:13

    It took me a while to get this working at http://step-by-step.org.uk/ on Firefox. The reason turned out to be that I am using other <link> elements without a rel attribute, and the Javascript was choking on that.

    Your resolution.js needs an additional check that currTag.getAttribute("rel") actually exists before you go trying to read it.

    Good stuff though - helps my layout.

  31. 31/53

    pid commented on 22 September 2004 @ 22:41

    How about you store the result in a cookie and check the cookie state before measuring?

    That way a server-side process could also test & load the correct default, thus avoiding any delay, nastiness when swapping a live stylesheet.

  32. 32/53

    Malcolm Mitchell commented on 23 September 2004 @ 00:09

    To The Man in Blue:

    I'm mighty impressed by this very elegant solution!

    I would like to point out however, that in IE 6.0.2900.2180, it fails to work. It renders the "Features" stylesheet by default (at 1024 x 768), and thus isn't affected by resolution change/browser resizing. This seems to be what you stated IE5.x does.

    To Darrel (21), and Philipp Lenssen (22):

    Resizing Firefox initiates the script, and does infact change the stylesheet — so it is working regardless of my resolution. Changing my screen resolution of course does as intended too.

    [As Alan P, I'm a lurker, but an <em>ir</em>regular one! This visit, referred by Simian Design.]

  33. 33/53

    The Man in Blue commented on 23 September 2004 @ 00:25

    Hmmmm ... works in my IE 6.0.2800.1106.

    *shrug* it's not use-as-is code, just a proof of concept. Nothing that a little tinkering and the usual optimisation (cookies, script load timing) won't be able to fix.

  34. 34/53

    VALENtine commented on 23 September 2004 @ 08:35

    I've been doing this for a while. Check out http://www.tomauger.com for an example of multiple columns, depending on window width. Works in IE and NS, not sure about Safari or Mozilla.

  35. 35/53

    Lysanne commented on 26 September 2004 @ 00:49

    I looked at it on IE 6.0 from a Windows NT platform and the layout didn't change no matter how much I resized (well, it was liquid, but it didn't turn into a 1-column layout).

    ??

  36. 36/53

    mattymcg commented on 27 September 2004 @ 07:42

    Nice job Cam. I like your Dr Seussified Lorem Ipsum too.

  37. 37/53

    Bochi commented on 28 September 2004 @ 04:56

    Ad [4] "Things are so much easier at 1280... Try 1280x1024."

    Right, however, you should use 1280x960 instead. 1280x1024 distorts the aspect ratio which is 4:3 on the most of screens and commonly used resolutions.

  38. 38/53

    Marschant commented on 28 September 2004 @ 20:42

    Personally I've always wanted more space on screen but browsing at 1280 x 960 creates problems of its own, namely legibilty of super-wide paragraphs.

    Legibilty breaks down when width exceeds around 40em's so if you're browsing at a high res then your font-sze should be scaled accordingly otherwise you're trying o read paragraphs 800 pixels wide or more.

    Just my two cents worth.

  39. 39/53

    manu commented on 29 September 2004 @ 03:56

    very cool, makes perfect sense!

    Thanx

  40. 40/53

    Anthony Yager commented on 1 October 2004 @ 11:16

    The Sydney Morning Herald http://www.smh.com.au/ has a two width displays greater than 1024 and less than 1024 and this is used for the whole fairfax site.

    For details see here http://smh.com.au/redesign/ for a switchable example see here
    http://smh.com.au/aboutsmh/index.html (switch is at the bottom)

  41. 41/53

    Peter Ottery commented on 6 October 2004 @ 13:37

    Anthony [40] said:
    for a switchable example see here
    http://smh.com.au/aboutsmh/index.html (switch is at the bottom)

    ouch. thats a mistake. That switch isnt working properly. am going to have a 'chat' to the developer now :) Its supposed to be a manual override of the javascript that does its best to auto detect the appropriate width and dish out the appropriate css.

    Anyway, great article Cameron.
    And great to see some other examples there from other commenters that show similar ideas in action.

    fwiw, The way we implemented it on smh.com.au & theage.com.au websites was a result of a wide range of needs and compromises - and it definately aint without its faults. In saying that, after a far bit of inital feedback on the point at which the "wide" stylesheet kicks in (currently set at an inner browser window width of 829px), user feedback on this 'feature' has all but vanished while other good comments continue to come in. So, yeah, i think its a concept that's well worth investigation. I think we'll see the concept taken to the next level in the next few years and get some really smart stuff happening.

    Keep em coming Cameron :)

    pete ottery
    fairfax digital

  42. 42/53

    Ethan commented on 14 October 2004 @ 06:52

    Very nice! :-)

    But what does come to my mind right now, without any testing, is: wat if Javascript has been disabled by the user?!?

  43. 43/53

    paul haine commented on 14 October 2004 @ 18:56

    Ethan: On the example page with javascript disabled in Win/Opera 7.54, the 800*600 stylesheet is used, no matter what size the browser window is.

  44. 44/53

    Owen commented on 15 October 2004 @ 01:46

    The best example I've seen is another Aussie site, <a href="http://whirlpool.net.au/">Whirlpool</a>, and has had this feature for years(?).

  45. 45/53

    The Man in Blue commented on 15 October 2004 @ 09:35

    Actually, that's probably the worst example I've seen.

    Why? Because they merely hide/show content -- anyone with a lower resolution misses out on the content that higher resolution gets.

  46. 46/53

    markyB commented on 13 November 2004 @ 08:52

    that's really cool i like it but im kind of new to this. Could you explain how it works in newbie terms? Sorry just learning still
    thx regards
    Mark

  47. 47/53

    Matej commented on 18 November 2004 @ 08:26

    doesn't work for me :o(
    OS X, Safari....

  48. 48/53

    Terry commented on 16 December 2004 @ 02:36

    I think the original cartoon lyrics were not:
    close friends get to call him T.C., providing it's with dignity.
    but
    close friends get to call at T.C., providing it's with invitee.
    In the early 80s, the new lyrics were decided upon and added to the pre-existing (earlier copyrighted) music

  49. 49/53

    Justin commented on 23 December 2004 @ 05:27

    Matej:

    It might be helpful if you noted which version of Safari you're running. ;)

    I'm using Safari as well and it works fine.
    1.3 v168

  50. 50/53

    expert commented on 31 December 2004 @ 18:39

    this is properly the best usen method now.

    there is no need for more than one css files for different resoulations.

    just have a master div tag, which sets the distace from left and right margins from the page. wola it does the job.

  51. 51/53

    Ed commented on 11 February 2005 @ 07:22

    I can't fault the execution but do wonder as to the benefits. At home I have a Sony GDM 21" monitor with a 1600*1200 desktop. I run Firefox at a window size of a little over 1024*768. At work I have a 17" LCD and run Firefox at a maximised 1280*1024. That's about as big as anyone would surely run their browser. I will admit to seeing the odd 640 wide CSS powered site and thinking of celery but it's never that bad.

    Also, serving different stylesheets means serving different designs which may cause confusion with familiarity if abused.

    One good aspect of this solution is more a document structure issue. I much prefer having the sidebar information in a DIV below the content DIV. Most CSS solutions I have seen that offer fluid content / fixed sidebar have the sidebar over the content. This may make accessing the content tiresome with other devices and readers as well as search engines having to sift through sidebar stuff to get to the meat of the site.

    Apologies for my late comments, I only just found this article and am currently playing around with it. Not having scripted ECMA to an advanced degree I haven't even considered taking things this way.

    Maybe I'm a simple creature and prefer things as such. :o]

  52. 52/53

    fambi commented on 21 March 2005 @ 04:40

    I've been trying to do something similar but FireFox doesn't seem to comply with screen.width or window.screen.width.

     

    Anyone else experienced this?

  53. 53/53

    Charles Martin commented on 24 March 2005 @ 03:16

    As an aside (sorta), if you resize the FireFox window to 640x480, the vertical scrollbar disappears.  This is a known bug and has been around a while.  The workaround (if you MUST test in FireFox at 640x480) is to resize the window to that resolution, then select File, New Window.  The new window contains the scrollbars as it should and you can then proceed with testing.

  54. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed