CSS Layouts: The Fixed. The Fluids. The Elastic.

Which Cascading Style Sheet (CSS) layout is best? All have their quirks and their unique pros and cons. Is one more accessible than the other? More usable? What are the drawbacks and how are they dealt with? Is one easier to create than the other? Is there an evil, inaccessible layout? I suspect some will say yes to this, but I’m not going to. I like them all and feel all are suitable if steps are taken to ensure easy usability and equal accessibility. All are part of a web site’s presentational layer, so most of the accessibility relies on the extractable semantics and proper usage of the underlying mark-up. What follows is my take on the rigid fixed, the adaptable fluid, and the expandable elastic layouts.


Fixed Width Layouts

A fixed width site is one where the main wrapper is set to a specific immovable width independent of the user agent’s display resolution. A common and considerate fixed width is 760 pixels, a size that ensures users with 800×600 resolution monitors have close to full window viewing without annoying side-scrolling.

The Fixed Width Pros
The main readable content area is tightly controlled without having to set minimum-maximum width (which isn’t universally supported, anyway).
Fixed width layouts are sometimes easier to style depending on the effect you’re after. Some visual designs can only be achieved in a reasonable manner with a fixed width layout.
Based on the example width above — 760 pixels — the typical main content area will be in my opinion an ideal width for optimum readability.

The Fixed Width Cons
My precious “ideal width for optimum readability” pro-listing above can go bad if the text is enlarged greatly since the line-width-to-text-size ratio doesn’t increase along with text resizing. Do note, though, in a good design, this is only a problem if the text is huge.
People with small monitors (640×480 pixels) will end up with a horizontal scroll bar on a 760 pixel fixed width site. This is a very uncommon problem.
A 760px fixed width site can look too narrow on large screen displays.
The narrow width can limit the reasonable number of columns and content, but this may actually be a pro. Think forced moderation.

Some Fixed Width Advice
Place your fixed width content on the left hand side of the page so on a typical site 640×480 pixel monitor users won’t have to side scroll to read the site’s primary content.
Be sure to provide a handheld style sheet to accommodate smaller devices. Supplying projection and TV media-type style sheets may also be a good idea.

Fluid or Liquid Layouts

A fluid or liquid layout is created by not specifying a wrapper width at all or doing so using the percentage unit of measure. In other words, barring borders and padding screwing things up, a 100% width site will take up the entire view port width without producing a horizontal scroll bar.

GrayBit.com is an example of a fluid width site. It resizes to under just under 755 pixels before sprouting a scroll bar, but the use of the scroll bar isn’t required to access the content. In fact, the site remains perfectly usable down to about 560 pixels after which elements start overlapping, getting concealed, or dropping. Most fluid layouts have limitations like this and most that I’ve seen don’t perform well on handheld devices unless styles are removed or a handheld style sheet is furnished.


The Fluid Layout Pros
If done right, a fluid or liquid layout can adapt to just about any view port width making it quite universal. This is seldom a reality, but in theory, and if care is taken to ensure it, it is possible.
Fluid widths match the browser default layout method making this the “purist” of them all. But does a developer’s want of site purity sometimes stand in the way of usability? I think it may.
The fluid layout makes the most out of available screen real estate. More content should be above-the-fold (meaning it’s available without scrolling in any direction). But…

The Fluid Layout Cons
Too much available content and a strong desire to fill white space can be a detriment to usability. Too much content can confuse the user and make a site too congested or cluttered. There is an expression: “White space sells” and it’s a truthful statement, even on the web.
If width limiters using the CSS property max-width — which isn’t supported by Internet Explorer (IE) version 6 or older, by the way — aren’t supplied, you may very well, in your quest for layout purity, create a site that is at best difficult to use. Try reading a line of text that is over 1000 pixels wide and you’ll begin to see the problem.

Some Fluid Layout Advice
Use this layout method purposefully. Don’t do it because it’s “pure” and for no other reason. I suspect there has to be a better reason than this. If you do create a fluid width layout, make sure it fits in a large variety of view port sizes. Else, why bother?
If you’re making a fluid layout site and have fixed width content areas, you have essentially made a fluid/fixed width layout hybrid and can only be as narrow as the width defined by the fixed width content section or largest object. Be careful. If you’re going to make a site that is fluid, make sure it’s really fluid and not just in name only.
If you do create a fixed/fluid hybrid anyway, like that shown on my CSS tutorial, make sure it fits 800×600 view ports.

Elastic Layouts

An elastic site’s main wrapper and other elements are measured using ems as the unit of measure. Ems are relative proportionally to the text or font size. Thus, as the text size is increased, the sections measured in ems will increase in size as well.

An elastic width example can be seen in my CSS Zen Garden submission (limited elastic-fluid hybrid). To the best of my knowledge, this is the only CSS Zen Garden submission that is elastic and meant to be as accessible as the non-editable markup would allow. I’m proud of this project.

The Elastic Layout Pros
If done right, this is a very stable layout method because everything resizes at the same rate. The result is nothing changes disproportionally.
An elastic layout is challenging and cool as hell. The first time I saw one was Tommy Olsson’s site (which happens to be an exceptionally well done example of how an elastic site should be done). This blew my mind, made me laugh, and generally impressed the hell out of me. Elastic width sites are best enjoyed by enlarging the text using ctrl and mouse scroll wheel… let me hear you say “Zwoop.”

The Elastic Layout Cons
Aside from the cool factor, I don’t really see much of a benefit to this type of layout. This makes me wonder what the point is.
Unless limited, this layout method can be a usability disaster as it’ll get wider and wider and wider — without benefit.


Some Elastic Layout Advice
If you’re going to make an elastic layout, make sure it works on small monitors. Else, what’s the point?
Limit an elastic layout specifying a max- pixel or fluid width measurement (hybridize it). For instance: #wrapper { width:60em; max-width:98%; }. Purists may argue that it’s not a true elastic layout if it’s limited or hybridized, but I really must ask: who cares? Again, layout purity is all fine and good, but not when it’s at the expense of usability.
Remembering that IE 6 and older doesn’t support max-width, try to start narrow enough that the text can be enlarged to its highest IE setting without producing a scroll bar at 1024×768. You’ll see that is the case with my CSS Zen Garden submission. To step it up a notch, you can make it narrow enough that it’ll be enlargeable to it highest setting in IE on an 800×600 monitor as well. An example of this can be seen on my skinny elastic web hosting site (limited elastic-fluid hybrid). I do plan to re-do this in less than a year, but the link is good for now.

In Summary
As you can see, all of these layout methods have their pro and cons (can you think of others?). As far as which one is better I don’t know. It is just a site’s presentational layer as I noted previously, so with a little care and consideration, I think all of these methods are solid and usable when creating accessible, usable sites. That said, I do suggest not falling into the web purist trap of doing things because they’re more “pure,” sometimes at the expense of usability or accessibility. I’m not trying to criticize those self-proclaimed purists, they make us think and are a source of insight, but if you follow that route, do so cautiously. Have a purpose and a plan. “Just because” is not a reason — or so I tell my kids.