99 (CSS) problems, but liquid ain’t one

Experiments with liquid CSS layouts

Experiments with liquid CSS layouts

We all know liquid is important, right? (Doctors recommend 1.5-3 litres per day :P)

Some of you may have been fooled into thinking liquid and elastic layouts died as soon as browsers deployed native zoom a few years back. I’ll assume you understand – with a fair degree of knowledge – the technical and usability ramifications of implementing fixed-width, liquid, and elastic web layouts. If not, then the following should briefly clear the haze:

Fixed-width layout

Dimensions have a fixed-width pixel (px) measurement.

Fixed-width is the easiest and most common type of web layout. If a content column width is 300px, then you know your image has to be 300px wide to fill it. Both column and image will always be 300px wide.

Generally less consideration goes into how these types of UIs will adapt, scale, and mutate with the addition of new functionality, content, and features. Typically they fail over time as a result: smaller resolutions (below 300px wide) become overly congested with elements protruding from their native spaces and line-lengths become so small you’ll spend more time locating the scrollbar than the new content. Larger resolutions fair no better (over 1280px wide) as designs look stranded, with excessive amounts of wasted white-space.

Liquid-width layout

Dimensions have a relative-width percentage (%) measurement.

The most difficult type of layout to achieve well. A thorough understanding and anticipation for the way each element will react to change is required. Elements react to available space, providing the opportunity to increase click-able interactive areas in size, improve UI robustness, accessibility, and affordance (see Fitts’s Law).

Developed successfully they radiate flexibility; allowing new components to be introduced without breaking the overall layout.

These sorts of layouts call on all three types of common web measurement: px, %, and em. (It’s taken me over 3yrs of practice to appreciate and utilise the subtle differences.)

Elastic-width layout

Dimensions have a relative-width em (em) measurement.

The advantage of more expansive, flexible, line-lengths using liquid layouts can also be a disadvantage for some designers. Once upon a time when IE6 dominated browser market share, and before modern browsers gave us browser zoom and the luxuries of CSS properties like max-width and background-size (both of which properties IE6 offers no support for), solving problematic disadvantages of both fixed and liquid layouts led developers to devise elastic layouts.

Elastic layouts scale the whole design up or down incrementally based on the size of the font (em), not the width of the element (px) or the width of the browser (%). These steps correspond to font sizes (12/14/16/18px etc.) and rely primarily on em (em) unit measurements. Users with reduced vision, short-sightedness (like me :[), or cognitive disorders can utilise these steps to notch their default font size up or down accordingly.

Let the (device) browser do the work

There are a wealth of devices on the market in 2010, which will display – or attempt to display – your website, and a bunch of eager users to go with it. Many CSS experts recommend that we [CSS designers] stop fighting against browsers and work in harmony with them, something I believe in too. This web design ethic applied to the conventional use of the browser back button way back in 1999, fixed font sizing in 2007, and I will argue it applies now with accessible layouts in 2010. Ensuring that your layouts flex their muscle appropriately, not only in zoom mode, but zoom-text mode too, is important.

Summary

I have achieved a hybrid-liquid/elastic layout on this website by styling all internal containers with percentages (%):
body #page #header {
padding:3em 1em 1em;
width:100%;
}
body #page .content {
width:100%;
}
body #page .content #primary-wrapper {
display:inline;
float:left;
padding:1em 1em 8em;
width:62%;
}
body #page .content #sidebar-1 {
display:inline;
float:left;
padding:1em 1em 8em;
width:29%;
}

The external container (or wrapper) uses an em (em) value:
body #page {
margin:0 auto;
padding:0 5em; /* Allow for outer gutter and pagination btns */
max-width:106.66em; /* 1280px / 12px/1em */
}

Constructing things this way means all internal containers inherit an equivalent em (em) value in percentages (%). This saves us translating all internal widths to ems (em), which can be needlessly time-consuming from a developers perspective, in the event you’re looking to maintain a baseline or vertical rhythm.

Feel free to play with the width, min-width, and max-width properties on the #page element above, along with various value unit types (px/%/em), using Firebug to get an idea of how each browser behaves in zoom and text-zoom mode. Essentially switching your layouts between liquid, elastic, and hybrid liquid/elastic is easily managed through this single element alone.

2 Responses to “99 (CSS) problems, but liquid ain’t one”


  • Hello mate!
    How are you?
    I’ve just come across your website.
    My name is Luigi and I’ve been in Brizzle for the last 2 years.
    I am a creative and web designer and I work in town.
    It would be good to hear from you. I don’t know many fellow designers in town.
    Ciao!

    Luigi Claudio

Leave a Reply

ATTENTION: Feel free to use HTML - all the important tags should work. Please wrap your scripts in <code>...</code> - thanks!