Fixed or Fluid?

This debate amongst web designers has been going on for years. Should a web page be designed with a fixed-width layout, or is it better for the page to be 'fluid', expanding with the width of the user's browser window?

With the increasing interest in accessibility and usability on the web together with the rapid decline of 800 pixel wide computer screens and a rise in popularity of wide 'panoramic' screens, it remains an issue.

Ever since I began building websites I've never doubted that opting for a fluid design is in most cases a fundamentally poor decision. Some of the intelligentsia of web design have adopted fluid-type websites for political correctness, and a preoccupation with fashion has led others to join the bandwagon and follow suit. Other designers, thinking for themselves, genuinely prefer this approach. Either way, it doesn't stack up, at least not without some constraint over maximum width on large screens.

Fluid (flexible) width page layout

Advocates of fluid design argue that web accessibility requires it. The W3C Web Accessibility Initiative stated in 2002 that an accessibility evaluation should "test with different screen resolution, and/or by resizing the application window to less than maximum, to verify that horizontal scrolling is not required." Taken literally, this does suggest a fluid layout – so fluid that horizontal scrolling is not required even when the user resizes the window to a tiny width.

A point is reached, though, when parts of the page begin to break up (horizontal navigation bars in the header, for example) and columns of text are compressed to only two or three words per line. Columns begin to overlap each other. Images no longer relate properly to their surrounding content and throw up a horizontal scrollbar when the window reaches the width of the widest image on the page.

The Web Accessibility Initiative's own page (above) throws up a horizontal scrollbar when the window is resized down to around 400 pixels, so they can't have meant "verify that horizontal scrolling is not required at any width." A reasonable width of window below which horizontal scrolling is acceptable is therefore a matter of judgement. I would argue that below such a width, when horizontal scrolling occurs, the integrity of the page layout should remain intact with no parts of the design breaking up or content overlapping other content. This means setting the design to maintain a fixed width, in its totality, at some smallish size – perhaps 760 pixels.

Fluid layouts and usability

Another aspect of fluid layouts is the alleged usability benefit in filling the screen to present the maximum amount of content above the fold, minimizing the need for vertical scrolling. If people using a high screen resolution have difficulty reading any of the resultant excessively long lines of text, they can always resize the window to a more comfortable width, or so the argument goes. Big-screen users who habitually have two or more narrowed windows open at the same time will do this anyway (in which case, 'problem solved').

So it's all about political web-correctness: being seen to 'empower the user' and give choice. The question is, what proportion of web users actually want to be empowered compared to the proportion that don't. A two-column page layout viewed at a screen width of 1280 pixels is likely to have excessive line lengths that are harder to read than this optimal line length of about 12 words per line (or about 72 characters). This means that the first thing the user needs to do is use their 'empowerment' to narrow the browser window to optimise readability, and in doing this, they'll be pushing content down below the fold.

It would have been easier to have presented sensible column widths in the first place, and let the user flick the mouse wheel to scroll down the content as required.

Constrained fluid-width layout

Some designs are fluid only above or below a certain width of window. For example, the design may be fixed at 1024 pixels wide when the window width is greater than 1024 pixels, and fixed at 740 pixels wide when the window is less than 740 pixels wide, but be fluid in between.

The problem here is that whilst the some browsers (eg Firefox) respect maximum and minimum values for the 'width' property in a stylesheet, Internet Explorer 6 does not, and a JavaScript workaround is required. Simple to do, but relies on the user not disabling JavaScript in IE6.

Of course a fluid page needn't occupy the full width of the window. Empty side margins can be maintained as a small percentage of the total width, but this doesn't work too well because at small window widths the margins take up space required by the now-compressed layout. Again, JavaScript offers a workaround but with the same proviso that a JavaScript-enabled browser is required.

Fixed-width layout

What exactly is a fixed-width page? In its CSS Techniques for Web Content Accessibility Guidelines the World Wide Web Consortium (W3C) recommends the use of relative units of measure. They advocate the technique of using "ems" instead of pixels – that is a unit relative to the current font size so that everything scales nicely when the user selects a larger font.

However, the W3C also states that absolute length units can be used when the physical characteristics of the output medium are known, such as bitmap images, otherwise everything will not scale nicely. A fixed-width design using "ems" as the unit of measure for 'box-widths' (sometimes called elastic layout) widens out when the user selects larger text, and doesn't scale nicely in relation to any dimensioned images used in the design, especially background images that define vertical borders etc.

An elastic-type layout using "ems" for box widths also runs the risk of expanding beyond the width of an 800 pixel wide screen when the text size is increased, then requiring horizontal scrolling.

So fixed-width means literally fixed, using pixels as the unit of measure for the boxes that make up the structure of the design (relative units should still be used for such as font sizes and line heights). Some fixed-width designs require the user to scroll horizontally in smaller window sizes. The highly respected 'A List Apart' now does that when the window width is less than around 1000 pixels wide. I would opt for less, at around 750 pixels wide, to suit an 800 pixels wide screen.

This website has a fixed-width design at 754 pixels wide, aligned left so that when the window is resized, the design doesn't jog sideways.

Collapsible layout with fixed-width columns

Not everyone likes to see empty space at the sides of the page. One way around this is to set several fixed-width columns side by side so that they fill most of the window at a higher screen resolution (eg 1280 pixels wide) but the rightmost columns progressively nestle in beneath the ones to their left as the window width is reduced. Muffin Research Labs provides an example. Of course this is only useful if the website contains enough content to occupy several columns.

The important thing is that the designer can work with known column widths, irrespective of how many there are. 'Control' is a dirty word amongst some of the web design intelligentsia, but design is about exactly that: control. They see it as the designer trying to control the user, but of course this is just as much nonsense as saying that the designer of a car is trying to control the driver. Quite the opposite. The car designer is exercising control over the things that make up the essential driving experience.

Liquid is back?

Now, look at Douglas Bowman's beautiful designs for Adaptive Path and Capgemini, all fixed-width. In spite of his 2003 assertion that "this fixed-width stuff won't last long – liquid is back" it's lasted until 2006. He's a designer, so maybe he knows that design can't be left to the user. So do Dave Shea, Jeffrey Zeldman, Dan Cederholm, and Ryan Brill, plus countless others.

But then, perhaps the process of web design is passée. Why not give the user total empowerment?

Look Ma, no design!

Anyone familiar with blogging tools like WordPress and others knows that the design of a website can be switched by the webmaster from one theme to another at the press of a button. This is possible because the site's content is stored in a database and is semantically 'clean' – it contains virtually no design information at all – just content. The theme is the design, and there are hundreds to choose from.

Some sites leave the choice of design to the user. Again, a different design at the press of a button. So why not build the site with a simple semantic structure of boxes for the header, content, sidebar, and footer, and with no design until the user has selected one? A cookie ensures that the next time they visit, the site will be to the design they last selected – fixed or fluid – whichever the user prefers.

The World Wide Web won't all go this way. One of the great things about blogging tools and other content management systems is that they're bringing people to the web in droves, but there's a degree of dumbing down in making those tools foolproof. And businesses and other corporate bodies will want to maintain a single controlled identity on the web, with consistent design in support of their branding.

Posted Sunday, February 19th, 2006 at 23:13. Comments welcome.