Page style:

A Blue Perspective: Resolution dependent layout

Resolution dependent layout
21 September 2004

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

Comments

1/53. 21 September 2004 @ 03:27, Filosof wrote:

I had the same problem on a few websites..

thx you.

2/53. 21 September 2004 @ 03:49, Jeff Minard wrote:

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

3/53. 21 September 2004 @ 07:17, Coudal wrote:

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/53. 21 September 2004 @ 10:58, Jason Berry wrote:

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/53. 21 September 2004 @ 12:41, Nick Cowie wrote:

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/53. 21 September 2004 @ 13:18, Nick Finck wrote:

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

7/53. 21 September 2004 @ 14:43, The Man in Blue wrote:

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/53. 21 September 2004 @ 15:12, Keith wrote:

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

9/53. 21 September 2004 @ 16:21, Meitar Moscovitz wrote:

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

10/53. 21 September 2004 @ 17:12, Mark Tranchant wrote:

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/53. 21 September 2004 @ 18:46, Richard@Home wrote:

What a cool piece of code :-)

12/53. 21 September 2004 @ 19:09, Nick Cowie wrote:

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/53. 21 September 2004 @ 19:12, Jon Hicks wrote:

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

14/53. 21 September 2004 @ 20:21, Brad wrote:

(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/53. 21 September 2004 @ 21:12, Ron Selling wrote:

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/53. 21 September 2004 @ 21:49, The Man in Blue wrote:

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/53. 22 September 2004 @ 02:05, Alan P. wrote:

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/53. 22 September 2004 @ 02:37, Roger Johansson wrote:

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

19/53. 22 September 2004 @ 03:23, Andrew wrote:

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/53. 22 September 2004 @ 03:44, chris holland wrote:

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

Congrats :)

21/53. 22 September 2004 @ 04:27, Darrel wrote:

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/53. 22 September 2004 @ 04:45, Philipp Lenssen wrote:

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/53. 22 September 2004 @ 04:47, Philipp Lenssen wrote:

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

24/53. 22 September 2004 @ 05:07, Ben wrote:

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/53. 22 September 2004 @ 06:39, kenji wrote:

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/53. 22 September 2004 @ 07:20, Sandy McArthur wrote:

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/53. 22 September 2004 @ 07:29, Richard Hulse wrote:

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/53. 22 September 2004 @ 09:29, Mike Steinbaugh wrote:

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/53. 22 September 2004 @ 12:43, The Man in Blue wrote:

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/53. 22 September 2004 @ 19:13, Mark Tranchant wrote:

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/53. 22 September 2004 @ 22:41, pid wrote:

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/53. 23 September 2004 @ 00:09, Malcolm Mitchell wrote:

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/53. 23 September 2004 @ 00:25, The Man in Blue wrote:

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/53. 23 September 2004 @ 08:35, VALENtine wrote:

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/53. 26 September 2004 @ 00:49, Lysanne wrote:

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/53. 27 September 2004 @ 07:42, mattymcg wrote:

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

37/53. 28 September 2004 @ 04:56, Bochi wrote:

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/53. 28 September 2004 @ 20:42, Marschant wrote:

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/53. 29 September 2004 @ 03:56, manu wrote:

very cool, makes perfect sense!

Thanx

40/53. 1 October 2004 @ 11:16, Anthony Yager wrote:

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/53. 6 October 2004 @ 13:37, Peter Ottery wrote:

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/53. 14 October 2004 @ 06:52, Ethan wrote:

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/53. 14 October 2004 @ 18:56, paul haine wrote:

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/53. 15 October 2004 @ 01:46, Owen wrote:

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/53. 15 October 2004 @ 09:35, The Man in Blue wrote:

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/53. 13 November 2004 @ 08:52, markyB wrote:

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/53. 18 November 2004 @ 08:26, Matej wrote:

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

48/53. 16 December 2004 @ 02:36, Terry wrote:

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/53. 23 December 2004 @ 05:27, Justin wrote:

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/53. 31 December 2004 @ 18:39, expert wrote:

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/53. 11 February 2005 @ 07:22, Ed wrote:

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/53. 21 March 2005 @ 04:40, fambi wrote:

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. 24 March 2005 @ 03:16, Charles Martin wrote:

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.

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.