CSS-based liquid layout has proven successful during the reign of 800-pixel to 1024-pixel screens, but as we use a wider range of devices to access the web, we need more powerful and flexible ways of managing layout. If we want to serve devices whose viewports range from 240 pixels to about 1680 pixels—and with resolution ranging from 72 to 150 pixels per inch—we need a new method.
What’s the problem with liquid layouts?#section2
If you create a liquid layout optimized for a maximum width of 1024 pixels—limiting maximum line-lengths for your text to maintain readability— gaps will appear on a wider screens, and your carefully balanced layout will break. On a tiny-screened PDA, your text and images will be compressed into a crowded content sandwich. No designer wants that. If vector-based layouts were technically possible on a wide range of browsers, we could use a single generic layout that looked exactly the same on all screen sizes. Since that’s more fictional than feasible, we have to find another way.
So why don’t we just define layout and appearance for a series of screen-width ranges, then find a way to match these layouts with the user’s viewport size?
Switchy McLayout to the rescue#section3
Switchy McLayout lets you define the dimensions, information richness, and appearance of your content objects for set ranges of screen sizes. A news site, for example, could have one layout and appearance for wide screens, one for medium-sized screens, and another for PDAs. Images could shrink or even disappear according to the screen size, columns could come and go as needed to maintain readability, and you can achieve a more efficient use of the available space for each screen size.
This example news page uses Switchy McLayout. For purposes of demonstration, we’ve defined seven screen-size ranges and given each range its own layout that makes effective use of the available space. CSS used in examples is for demonstration only.
Figure 1: The progressive states of a news item’s appearance.
The page’s degradable, unchanging markup for the page contains all the items shown in the “extra wide” layout. As the viewport size diminishes, various kinds of content are changed. It’s like peeling an onion: every time the screen shinks, a layer is removed, until only the essential parts remain. The ranges and corresponding appearance defined for this example are:
| Device | Screensize | Layout |
|---|---|---|
| PDA Vertical oriented | < 240 px |  |
| PDA Horizontal oriented | 240-320 px |  |
| Set top / TV | 320-640 px |  |
| Old CRT screen | 640-800 px |  |
| Common TFT screen | 800 – 1024 px |  |
| Wide screen | 1024 – 1280 px |  |
| Super-wide screen | > 1280 px |  |
Class switching#section4
Now that we’ve defined a range of layouts, we have to detect the user’s actual screen size and activate the appropriate group of styles. We’ll use a style-switching method that’s dependent on the class of the body element.
JavaScript, our CSS assistant#section5
To monitor the user’s actual screen size and switch classes on the body-element, we use a little unobtrusive JavaScript. Through the onresize event of the window object, we obtain the windows/screen size. A ternary operator selects the appropriate layout and class name, and this class is added through the DOM to the classes already residing on the body element. When JavaScript is not available, the layout degrades to an “old-school” liquid layout.
Note that different browsers use different event models. IE6, for example, fires the onresize event in real-time, while Firefox only fires the onresize event at the end of the actual resizing.
Progressive content compression#section6
Our second example shows how Switchy McLayout can help us make more efficient use of available screen space on different devices. In its raw form, the markup is a simple definition list with four items. On wide screens, all items and headers will be shown as four columns in a row. As available space decreases, the columns will be shown as two rows of two columns, then as a horizontal tabbed panel, then as a vertical tabbed panel, and finally as four rows in one column with a reduced font size.
Figure 2: The various states of progressive content compression
Taking it further#section7
We’ve used the screen size property as an input for class switching. If you used other triggers to switch styles, you could check for screen height, presence of a scrollbar, font size, mouse position, color depth, and so on—and change your page’s appearance accordingly.
In conclusion#section8
The growing number of popular screen sizes and resolutions will challenge web designers to deliver their content in an appealing way for a wide range of devices. Switchy McLayout is a step toward a solution that meets this challenge.
Acknowledgments and alternatives#section9
While the technique presented above was developed independently, many related techniques have been introduced elsewhere. Richard Rutter collects a series of such techniques at Clagnut, and Kevin Hale presents a technique that achieves a similar result using a slightly different method at Particletree. Andy Clarke and James Edwards’ pioneering “Invasion of the Body Switchers” helped popularize the use of body classes to alter layouts.
How I wish I could deliver a template like this to my current employer. Alas, I am still getting them to stop developing Windows IE-only apps for the general public at large. I’m happy at the moment just getting them to accept my “alternative” (ie, standards-compliant) markup with a stylesheet switcher. Well, I delivered the template eight months ago and it’s still in limbo hell.
Thanks for the article. It will be well implemented by me somewhere for someone. Just not for my current paycheck holder.
Nice technique! but.. unfortunately non of my clients will wait me to make 5 different css files. I need something more universal. 🙂
This is excellent, I’ll definitely be looking at this a lot closer. I guess I’m lucky that I may get a chance to implement this in current development.
As always you are an inspiration.
Thanks for the article it’s fired up a load of ideas.
Nice try, but I think that lots of work needs to be done to adopt this technique. Also, when I resize browser (Firefox 2.0 win) to 754px — screen_low, layout breaks. I don’t know a lot about PDAs or other alternative devices mentioned, but how about their’s Javascript support?! For now, web designers should still make different pages for different users – without using Javascript – different CSS and PHP maybe. Or am I just to conservative 🙂
Made-to-measure. And it is far better then one liquid layout for many viewports. Congrats. I’ll have to use it in near future.
And what if i would like a window with the actual “huge” layout and i resize it to a smaller size? For example i read something, then i want to copy several passages to a text file. For this i resize the Browser and start my text editor next to it. But all the interesting text suddenly disappeared or moved somewhere else. Maybe even the picture disappeared that i wanted to save.
I think for really small devices like PDAs or even phones you not only have to adapt the layout, but also reduce content.
Does the JavaScript detection work on all browsers (of course with JavaScript enabled)? Like for example Opera mini?
If JavaScript Detection fails you have to find a default. And the default has to be different for different user agents. So your technique only makes sense combined with some other logic.
Or, you can always choose to make a http://www.domain.com and a http://wap.domain.com (or http://www.domain.mobi).
I totally agree to Dragan that you should not change the layout when a user resizes his browser window. Instead I would use the available screen size as the selector for your layout.
Cracking concept, well done.
As others have said, I can see some issues ;-
– Resizing the window causes the content to change
– Large images will always be downloaded (bad for mobile phones/PDAs)
Someone suggested using the ‘available screen area’, I think this alone would be a bad idea because I’m lucky enough to work with wide screen monitors (>1920 pixels) but seldom have browser windows open wider than 1280, usually around 1100.
I think if there was someway you could perhaps ‘remember’ the initial setting that the browser open the URL at, this would be a solution, though how you’d “remember” such a thing is beyond my ability.
All that said, this is a simple, yet brilliant observation. That people will be looking at your pages on many many different sized screens, allowing the to read/view the ‘meat’ of your page is the essential part.
Most deffinately, food for thought.
Ever since I’ve had a 1024 pixel wide monitor, I haven’t used my webbrowser maximized anymore. My browser window is commonly actually about 800-900 pixels wide. I really can’t understand why people measure screensize, while that says nothing about the available display area in the browser. But maybe I am a special case.
The modified layout problem on window changes is easily fixed; don’t change the layout on resize, only on load! That way you can change your window size (for example to have an editor alongside) without the layout changing. But note to Dragan: it has always been common that text re-wraps when you change the window size, so pictures and text do end up at different locations. Unless you like horizontal scrolling!
One more thought; how about implementing the screen-zoom features of IE and Opera. At a lower zoom-value, you can show a higher-resolution layout…
But what about the 5% procent of people who have javascript turned off, is there a default state.
maybe a liquid “by nature” site, could be hijacked (javascript enchanced to behave better.
This technique is interesting for sure, but it doesn’t really solve the issue of designing for all screens. This problem is not best solved with javascript. If we’re targetting users with obscure screen resolutions, chances are we’re also targetting obscure browsers which means we cannot assume javascript is supported. Perhaps a better solution would be to use “switchy layouts” in conjunction with serverside UA detection for custom css or the lesser-supported CSS media type.
I was excited to see this article because the varying sizes of devices nowadays certainly does pose challenges; I was hoping to find salvation, but I am sort of disappointed by what I saw.
First of all on my 1024 res display the content took up only about a third of the available real estate.
Second, without JavaScript support the layout broke — it did not revert to a liquid layout. The image got wide but the content area stayed as is and made some of the text hard to read as the image went behind it. (I did re-load the page.)
For now I guess, for me anyway, I will have to stick with reasonably sized fixed width (760px) or old school liquid layouts, add max-width for monitors that are super wide (using browsers that support max-width), and rely on a handheld media-type CSS for those little devices.
I did base these comments on what I saw on the demo page, and maybe that page is at fault, but I had nothing else to go by. I do appreciate the technique though and hopefully with some refinement it might be a more usable solution. I will recheck the demo page to see if it gets updated at which time I may reform my opinion.
(I’m using FF 2.0 on Win)
Cool man! I have to implement this! It’s too dope not to get used!
*@Erin Kissane:*
The point of my comment was not to ask “what happens when javascript is off or unavailable” but more to note that the solution to the problem of designing for ALL screens is not solved by using javascript. Most browsers written for small screen devices do not support javascript and therefore this technique will not work, despite the fact that this article implies that it will.
This is pretty useful and I also did something like that around a year ago.
BTW, I’m not shure that more than 3 types of layout will be useful, mostly because all we have limited time of development.
Also real deal will be after more browsers implement “CSS3 media queries”:http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/
For now only Opera and probably Safari/Konqueror support it.
I like the pragmatic approach of this solution. I think 7 form of a layout is far too confusing for real world application, since resizing browser windows on a big screen results in a changed layout. For a demo this is of course perfect to illustrate a point.
However, for small screens this technique is promising… but most small screens I have tested on (PDA and several phones) have a very lousy support of javascript and CSS.
Most phones will handle the ‘default’ css instead, the liquid layout, or if available a handheld stylesheet. Which will leave us with two baic sheets: a standard liquid and an adapted big screen layout (maybe two for some designs: a 1024 max and a wider one). But most of that could be achieved using a max width CSS2 propertie for really big screens.
In the end I’m afraid that the real world application of this is rather limited (or gimmicky) due to bad browser support on small screen device. For large screens, I’m not so sure I would like to confront a user with a totally different layout depending on the screen size, to avoid brand confusion. Of course there are cases when this could apply (online newspapers, BBC News) to use as much screen estate as possible and still keep it readable, but still I would test this out on a target audience before I would apply different layouts.
The question then would be what the return on investment would be on the added maintenance costs of a couple of stylesheets and I wonder how many websites would actually benefit form this business wise.
In the current stage of web development, it’s a great solution. I’ve checked both (fixed) layouts in all my MAC/PC browsers and it seems to work awesome. I’ve been developing a site using the Particletree approach by Kevin Hale, but this seems to load better in IE/PC.
I wonder if all the criticism is due to the styles used? Looking at the execution alone you can customize each stage to your heart’s content. Why complain about all the stylesheets? Just keep them simple if you don’t want to use them.
No javascript? Fine…just degrade to a default stylesheet. Folks without JS are used to MUCH worse!
Check my site in the new year and you’ll see one of these implementations used. Thanks Marc and ALA.
Wow ALA. You don’t accept html entities in comments?
… should be …
I find the approach of liquid layout very interesting to read and discuss!
But I just don’t see a practible use in developing a side that way. Too time consuming.
How about just using a min and max width in CSS and everything inside degrades gracefully to any Screen Size without any Java Script.
A flexible Layout looks good on Grandma’s 15″ Screen PC, or a Yuppies 22″ Monitor and it looks also acceptable on a 30″ Developers Monitor.
Aren’t most books we read, a certain size. It is cumbersome to read a 30″ long line of text.
Heh, I guess the heading says it all. Thanks Erin.
I think it’s a great concept and some nice demos. It’d be nice to see how other people apply it. I’d like to try it out, but, sadly, in its present state, it’s cost-prohibitive to design more than one layout per site, although when I put together a new layout for my site, I think I’ll give it a whirl.
I really like the concept. I also like the number of colorful pictures used to illustrate the point 😉
It might not work for every situation but I think it would definitely be a ‘cool’ feature to implement on the right kind of site.
Incidentally I just tried the demo page on Opera Mini and it returned 800px on every device I tried it on, I guess it’s the way the proxy deals with the pages when it’s compressing them…
Thanks for a good read.
Does it seem like ALA might be an appropriate place to implement something like this?
You can do the same thing with css @media property:
@media screen and (min-width: 400px) and (max-width: 700px) { … }
Hi Szymon,
You are correct and it would be very nice to have!
But as far i know, Media Queries are part of the CSS level-3.
Currently they are just a W3C recommendation…
With this in mind i think it would take a long
time to see this feature implemented in a x-browser way.
Just some css level 2.1 compliancy would be nice
to have these day’s !
Like others mention, in the real world at this present time, I don’t see my customers (who crab about costs, finding a budget for this sort of thing… so I would end up doing volunteer work.
However, it’s nice to keep informed with what one could do if one had unlimited time and money was no object. It’s edgy avantguarde stuff. Sort of like Vogue, the average folks wouldn’t wear the fashions around the office, but it pushes the envelope and makes the designers think in new ways.
Great job.
…when people said switching to CSS driven layouts was too avant garde, that there wasn’t a business case for it, and that the browser support just wasn’t there…am I getting old?
I was initally sceptical about this article and the use of Javascript, but by the time I got to the end of it I have to say I was convinced it’s a good, solid basis for people to start fleshing out the concept.
I can see lots of ways to implement this to solve resolution problems I’ve been wrestling with (as I’m sure many have) for a long time. Until now, elastic layouts were the only semi-acceptable solution I could find.
The important part of it, I think, is that it is pushing the concept of adapting the content to suit the browser. If that notion gains more traction, then when the browser support for CSS3 media queries comes of age, the take up of that solution will be far more fluid…erm, adaptable?
interesting concept, has some problems as people have suggested, but i’ll support 100% anyone who wants to knife liquid layouts. the sooner they go the way of framesets the better.
I love the concept, the implementation however leaves a little to be desired. I’ve added a subtle example of it to my website:
http://www.dunedinicehockey.co.nz/
On resizing to <640px the page border dissapears showing real content in it's place. The information boxes at the bottom of the home page also shift around.
The thing I don't like is that my borders pop back into place for a few seconds whenever you switch to another page 🙁 So although the concept is sound, in reality there are still a few issues with it. I'm happy with it in it's current form on my site as below 640px you really do need the extra screen area, so a bit of flickering on page changing seems like a reasonable tradeoff, but for use in common browser widths I see there being significantly less use for this technique.
As I was reading this article I thought it was great. But after I thought about it and changed idea.
quickly:
1. This solution affects the window-resizing. If I resize my window I’m going to see disappearing elements. It’s confusing and unusable.
1b.As written in a post before,I could have problems while printing page.
2. The elements flicker.
3. If the real problem are small displays, we can use the Css media type switchers display|handled|print etc etc. This would be the simplest and best practice for small screens.
While I was reading your article I was asking myself whether this way of implementing a layout got it the wrong way around. In my opinion web-design should not be too much focused on the users choice of the UA or OS in order to deliver the *best possible* and pixel-precise design, but instead a web-designer should strive for the most convenient way of presenting content.
If we all end up in designing 4 different CSS for 4 different viewing conditions we may find ourselves at the entrance of a one-way-road. As others mentioned the technique is neither future-proof nor is it useful for most users (since when am I forced to see a different layout, just because I decided to maximize my UAs viewport?). But worse: what will happen to those poor souls who rely on the ability of their UAs to enlarge the content via [ctrl]+[+]? They will see the layout the designer decided to be the best for their initially chosen viewport size, which may not be the best solution in an enlarged view, as enlarging means reducing the relative size of the viewport.
Why are we still using techniques relying on absolute pixel-precise positioning instead of developping solutions that rely on relative units like ’em’? An entirely ’em’-based CSS would allow the perfect representation of any sort of content in any UA regardless of the UAs viewport size. And please, use the media-selector in your CSS-definitions in order to address certain types of UAs.
I think these blog is really useful for new comers and Excellent resource list.
though i am inclined to agree that on resizing my window i don’t like to see things disappear and reappear differently. still its an interesting methodology and makes sense in many but obviously not all web dev. tasks.
Another fantastic article on ALA.
I used both my PC and my mobile phone (Sony Ericsson K800i) to play about with the examples, and they work well. I also turned JavaScript off in Firefox using the Web Developer extension and the content in the examples was very well structured.
It’s not something I’d look into producing myself just at this moment, but I’m definitely adding this article to my favourites for the near future.
I dont mean to be a big bubble burster, but the code / sample page is not suited to real-world deployment.
Consider the PDA. It will load in the full page, THEN adopt to the PDA styling. This will waste the low resources of the PDA and also the bandwidth. (If you check the CSS, even though it only shows a small portion of the image, its just cropped – the whole thing must load in!) – I’m sure you can continue this line-of-thought…
The better, and dare I say RIGHT, method is to check the Headers sent to the website and then decide what to do for the User Agent.
Mind you, the mobile industry have done very little to help the developers (and themselves) as concerning headers. I did read an outline document by the IETF specifying recommended headers to send, useful things like: dimensions (inner and outer), resolution (PPI) and colour. Possibly more. Of course not all devices can agree on what to send, and thus User-Agent is still your best bet.
A great article.
Personally i’m surprised there isn’t many sites optimised to the users screen resolution. Maybe this is “web 3.0” ?
I think that at this point there is no real alternative than to make a separate site for mobile. Developing for mobile is like developing for email, semantics and best practices are not the way… The javascript/css support just isn’t there yet.
I find this absolutely del.icio.us; great article, easy implementation. Thanks!
Interesting amalgam of already popular techniques. But this technique is not a revolution, so why do you name it “Switchy McLayout”? It doesn’t sound serious.
…so how would you approach this technique for email? end users could be on an array of different devices and clients (which largely block js), and the sender wants an image-rich delivery to those able to view it.
thoughts? discussions? articles? thanks!
What a nicely presented article. Great visuals!
First of all I’d like to thank everybody who has joined the discussion or who has cracked his mind on this technique before. To empower the discussion and give it some direction i’d like to clarify some things about this particular adaptive layout implementation.
Like some people commented, the techniques used in the examples aren’t that new or groundbreaking. Nor will it pretend to be most ultimate solution for the specific
problems whe have to deal with. The goal behind this particular implementation however is.
This article is definitly not about page-layout but it has a distinct focus on the appearance of _content items_ on the page in relation to the device whe use. Information richness, dimensions and appearance can be changed depending on the available screenarea on different devices.
The demo’s are created with just one goal in mind, demonstrate and clearify the mechanism. They are no cut ‘n paste solutions. So things like realtime-change-of-content-on-resizing like we use in the demo’s is certainly not usable. Instead, as stated in some comments before, define screensize once at pageload.
For me this article is a way to shake-up the css layout revolution. Nothing new has been introduced for some years now, and that worries me. Especialy the introduction of widescreen devices will eventualy create a new mind-set. While available screenarea on handhelds is very sparse, we got plenty of it on our widescreens. So following questions will rise:
How to handle this whole bunch of unused screenarea?
What can we do with this screenarea?
How does it fit in our webstandards way of building?
Well now, let’s take this example further. So modify it, implement it, polish it, talk about it, discuss it, let creativity lead us to some new idea’s and concepts. we are curious by nature, so let’s innovate!
It took me only a few hours to design a small site with low medium and high resolution.
A few minor ajustments to the script and it was very usefull. Dergrades gracefully, is unobtrusive. When you start with a nice low resolution version, it looks nice on a celphone, pda highres display without javascript.
The extra time you need for the extra css versions is with a good practice of cut and paste minimal in compare with the results. My thanks to Marc for the idea. Just try.
I have just finished reading this article and view all the code, as I am designing a brand-new web right now for wide screen, I think I have found thr right answer here.:)
You discussed what happens if JavaScript is disabled, but I question if this technique really works in most cell phone and PDA web browsers.
I have personal experience with trying to view “normal” web pages with the built-in web browser on my RAZR smart phone, Opera-Mini on a cell phone and a PDA and the PDA’s builtin web browser.
They all seem to ignore CSS.
So I guess it comes down to this question. Is CSS support for PDAs and Cell Phones is too poor for this technique to work in the real world?
P.S.
You could use this technique to control screen layout, but using it to eliminate displaying large media files seems futile.
As someone else mentioned – having to wait for the full content of the largest display supported to be downloaded before you detect that the device is really just a cell phone is a tremendous waste of bandwidth and time.
Maybe I’m just late to the party and declassé – maybe it’s not new in this article – but the thing that really caught my eye was in the second example, the degradation of columns into tabs. Kudos to Marc if that’s your innovation.
So this plan works well for simple pages like the example page, but what if I have some sort of a flash presentation or navigation system that I would like on the main page? Is there a way to determine if the browser is Portable, and then send the viewer to a different page?
The viewer visits the page on a regular Mac/Pc and gets index.php, but then if they have a Portable they get send to indexportable.html or something like that?
I did find:
http://www.apptools.com/phptools/browser/source.php
in my searches, but I am not sure if does exactly what I am looking for.
I see a lot of use for a technique like this, but not necessarily as many of the commenters have assumed. I see this technique more as a “progressive enhancement” than “graceful degradation”. That is, rather than use it to provide a more seamless, light-weight website for mobile devices, I’d use this to provide a richer, more fulfilling experience for those with wide-monitors and higher resolutions, which are almost an equal reality these days as mobile devices. I’d use it to add less-valuable content or simply mere decoration for those larger resolutions, and not to restrict content from those with smaller resolutions or less-capable devices. As previous comments have indicated, there are more-direct ways of accomplishing that.
IE reads my index page for screen size but not any others on my site when implementing switchy mclayout.
http://webdesign.tntech.edu/Design/ILO/index.php
any ideas?
I´m thanks for this website i have more information fo webdesign and css learning and inspired.
I know the point of this article was the javascript, but I also want to use this resolution-based column remapping technique you used in example 2. I really want to use a form of this technique, but I am new to using css. I think this is a potential bug in your screen_med implementation and hopefully it is an easy fix. To see the bug, go to my example here:
http://www.mineisbetterthanyours.com/test/switchyBug/
All I have done is copy and paste the last paragraph to make body tab A longer. When you do this and view the page in screen_med, instead of the layout being A B on one line followed by C D on the next, the order becomes A B followed by another “line” which has blank space and then C on the right column, and then the D section wraps back onto a 3rd “line” and is on the left. Does anyone know how to fix this? I just want there to be 2 columns that properly follow each other without any weird space. Thank you.
Its also crucial that they do this without the css defining a fixed height of how tall each section is going to be… (although how tall is not what matters, it just matters when they aren’t the same height).
Your technique only makes sense combined with some other logic.
I am very interested in using a simplified version of this on the new (all css version) of my site, but I notice it doesn’t work in IE5. You always get a clientWidth of zero. I don’t know much jscript. Anyone know how to get round this?
Awesome post, awesome discussion. I got enlighted for my new project. @All: thanks!
It is not quite the same. But similar enough to be mentioned: Another possibility is to use a CSS
* container with overflow:hidden and fixed width combined with
* (sub)containers with fixed height. As many columns are displayed as possible (this means, part of the content won’t be visible on small screens.)