The Smashing Book – The Art and Science of CSS-Layouts

• By The Smashing Editorial
• October 5th, 2011
• Layouts
• 0 Comments

← User Interface Design in Modern Web ApplicationsTOCThe Art and Science of CSS-Layouts (2/2) →

In modern Web design, the craft of developing a website’s layout requires patience, precision and solid knowledge of CSS. While design elements determine flow and hierarchy within the design, Web layouts build up the skeleton of the website, providing space and a structure in which the design elements can breathe and serve their role. But laying out a page is often tricky and time-consuming and can be undermined by browser inconsistencies and all sorts of trade-offs between various types and styles of layouts.

Good news: there are some practical guidelines that can help you approach these issues manageably and effectively. This article throws light on various kinds of layouts, shows their advantages and disadvantages and suggests situations in which each would work best. We’ll also talk about the main techniques and related issues for gaining a better understanding of CSS layouts in general.

The search for a “holy”, universal layout usually boils down to comparing existing approaches and will be heavily influenced by the designer’s skills and choice between pixel-perfect designs and adaptive, flexible ones. Essentially, designers have a choice of four major layout types: fixed-width, fluid, elastic and hybrid. These names refer to each layout’s ability (or inability) to adjust its dimensions (primarily its width) according to the user’s browser size.

Fixed-Width Layout

A fixed-width layout, as the name suggests, is a static layout whose width is set to a certain fixed value, in pixel units. Such layouts have a wrapper of a fixed width, and all components inside it have percentage or fixed widths. The designer has more control over the placement of design elements around the content areas and can work with content and navigation widths more precisely. Typography, graphics and proportions between website elements can be exactly pre-defined by the designer using general heuristics and rules of thumb. Fixed width ensures that these proportions always hold true and that the overall design remains the same, no matter what screen resolution the visitor has.

Fixed-width layouts are a popular choice because they are simple, intuitive and easy to implement and customize. With a fixed-width layout, you are assured that the design will look the same at different screen resolutions, so you don’t have to play a guessing game, and development time is reduced because of the fewer requirements for designing and for testing under various conditions. Specifically, these layouts work with straightforward “absolute” values (pixels), which many designers find more comfortable and intuitive to work with than percentage or em units. Pixel-perfect positioning of blocks of content is probably the most obvious advantage of working with this layout type.

Colourpixel’s portfolio has a layout whose width is fixed at 950 pixels. This is how it looks with the browser’s view port set at 1045 pixels.

The width of this layout is usually determined by average screen resolutions. Currently, most users have resolutions that display at 1024 * 768 pixels or more, so most designers will use between 960 and 1050 pixels for their layout’s width, which lets the user avoid having to scroll horizontally and gives ample leeway for the 20-pixel vertical scroll bar found in most Web browsers. Still, it’s important to notice that smaller screen resolutions may require a horizontal scroll bar, depending on the fixed layout’s width.

An advantage of fixed-width layouts is that design elements are easier to position and things are more predictable. Positioning elements is not complicated when you’re certain of the width of your layout. Besides, even if a website is designed to be compatible with the smallest screen resolution, 800 * 600, the content will still be wide enough at a larger resolution to be easily legible. Print designers who make the jump to Web-based media tend to choose fixed-width layouts because of the precise control of presentation they are afforded – after all, absolute positioning of elements is very common in print design.

Here is the same website at a different resolution: the browser’s viewport, at 1680 pixels, displays empty space to the right of the layout.

A disadvantage of fixed-width layouts is that they don’t take advantage of the user’s full browser area. Of course, screen resolution is not necessarily the same as the browser window’s resolution, because many “wide-screen” users do not maximize their browser window¹. However, if a user has a large wide-screen display (for example, a resolution of 1900 * 1200, and a browser resolution of 1500 pixels), it is reasonable to assume that a relatively large portion of the screen area is not being used. For instance, a fixed-width layout of 750 pixels on this display would leave empty space that is as wide horizontally as the layout itself!

Consequently, a fixed-width layout may create excessive white space, thus upsetting “divine proportion”, the “Rule of Thirds”, overall balance and similar design principles. Furthermore, seamless textures, patterns and image continuation are needed to accommodate those with larger resolutions. At the very least, centering the wrapper DIV is highly recommended, to maintain a sense of balance in the fixed-width design:

#wrapper { margin: 0 auto; } 

will do the trick. Or else, for users with large screen resolutions, the entire layout would be tucked away in the left upper corner.

And then there’s the big question of what the appropriate width is. Many users have large wide-screen monitors, but most have average-sized monitors, and some have still yet smaller screen resolutions. In any case, most users adjust the window to their preferred size and do not necessarily have maximized, standardized or proportional screen resolutions.

In practice, finding the “right” balance for a website’s fixed-width layout usually requires a thorough study of the profile of that particular website’s average user. Assessing your visitors’ browsing preferences and then leveraging your design accordingly is always a good idea. The most common way to do that is to analyze your website’s statistics to see which resolutions are the most prevalent and how many users use small screens. As a rule of thumb, you can usually create a good user experience by keeping the width of your layout to between 800 and 1000 pixels. As professionals, we have to create layouts for our visitors, not ourselves, even if that means that our designs look terrible on our own high-resolution wide-screen laptops.

Let’s create a simple two-column fixed-width layout, with a header section for the logo and primary navigation and a footer for additional website information. The HTML would be as follows:

<div id="container"> 
<div id="header"> 
<!-- logo, navigation --> 
</div> 
<div id="content"> 
<!-- main content --> 
</div> 
<div id="sidebar"> 
<!-- sidebar --> 
</div> 
<div id="footer"> 
<!-- site information --> 
</div> 
</div> 

To make the width fixed, we set a width on the #container DIV. We also assign a fixed width to the left and right columns. To make the header and footer equal to the container’s width, we give them a width property of 100% (which is unnecessary most of the time but good practice nonetheless if we want to make sure they are indeed equal to the width of the container).

We use the “float” property to display the left and right columns beside each other (of course, we could use relative or absolute positioning instead) and the “clear” property for the footer so that it displays below the two columns. Note that you would need to use some kind of global browser reset to ensure a cross-browser presentation of the layout.

#container { 
margin: 0 auto; /* Centering the layout horizontally */ 
width: 960px; 
} 
#header { 
width: 100%; 
} 
#content { 
width: 600px; 
float: left; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 
#sidebar { 
width: 330px; /* 960px - 600px - 330px = 30px is used to separate columns */ 
float: right; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 
#footer { 
width: 100%; 
clear: both; 
} 

Choosing between a fixed-width layout and another type is a question of how much freedom the designer is willing to give the user. The former entails that design decisions are more in the hands of the designer than the user, while the latter entails that components like fonts, images and columns will scale fluidly according to the user’s preferences.

An example of a fixed-width layout.

A common argument against fixed-width layouts is the difficulty of maintaining the code over a long period of time. If your design has a fixed size for the fonts in design elements (even if IE6 users cannot rescale the text at all), and your client requests a bigger size for certain design elements (for example, the text), you could end up with a “nightmare of changes and recalculations for an extra pixel on the text size” (The Fallacy of Page Zooming, www.allinthehead.com). A better approach would be to use relationships between elements to determine the essence of design proportions (i.e. using relative values). This is exactly where flexible (fluid and elastic) layouts come into play.

Fluid (Liquid) Layout

A layout with a fluid width, also known as a liquid layout, adjusts its width in proportion to the size of the Web browser’s view port. In such layouts, the majority of the elements inside the container are defined in percentage values, using the current properties of the browser window as the baseline. When the size of the browser window changes, so does the layout, because the baseline is changing with the user’s every adjustment of the browser window. In other words, the widths of individual layout blocks adjust automatically according to the user’s browser window. So, if a user is not quite comfortable with the line length of an article she is reading, she can simply resize the browser window, and the content block will shrink automatically.

In such layouts, the relationships between layout elements play an important role, because the widths of child elements set in percentage values are always determined by their parent elements (not adjacent elements!). For instance, if the width of the layout container (whose parent is the browser window) is set at 90%, and the width of the navigation block within the container is set at 80%, then the width of the navigation element is 72% of the browser area (1 * 0.9 * 0.8 = 0.72). As you can see, coding for such layouts requires a profound understanding of the structure of the design; designers may be more prone to error when working with this layout type, but a successful execution will make the website more flexible and adaptable for some end users².

Fluid layouts can take up a lot of the available screen space in browsers, making it possible for designers to distribute content evenly and with adequate white space. If designed properly, a layout will have a consistent amount of white space, regardless of the browser or screen resolution in which it is viewed, making the design more consistent and user-friendly. Also, such layouts can eliminate the obtrusive horizontal scroll bar when viewed in smaller resolutions.

Unlike fixed-width layouts, liquid layouts give users the freedom to decide the width of the layout they are viewing. With them, designers move away from rigid, consistently pixel-perfect layouts to a more flexible (and therefore riskier) environment in which the proportions between certain website elements are more abstract and difficult to define. No wonder that many designers avoid them. They take the predictability of positioning design elements with pixel-level accuracy out of the designer’s hands.

Because designers work with relative percentage values instead of absolute pixel values, they will often have to round some values up or down in practice (for example, from 15.433333% to 15.43% or 15%), making the design less precise³. While smoothing the values over works fine for smaller resolutions, the practice can result in quirky side-effects at larger resolutions, such as creating noticeable gaps in the layout or making the content area too wide and thus hard to read.

In fact, the latter result is the most significant downside of fluid-width layouts. Because the width of content is determined by the user’s view port, users with wide-screen resolutions will likely find that bodies of text have line lengths so long that reading them becomes cumbersome and uncomfortable. And if a particular page with a fluid width doesn’t have much text on it, the user may end up seeing only a couple of lines of text in the content area and a disproportionately tall vertical sidebar column with a huge amount of white space around it.

To solve this problem, designers often set a maximum width for the content block, thereby forcing a more or less optimal width for the layout. To determine the maximum width of a #content-block, many designers aim for optimal readability (47 to 86 characters per line) plus 10%. A minimum width is rarely set and only if the readability of the design would significantly suffer at smaller screen resolutions.

In CSS, the maximum width of a layout is defined using the “max-width” CSS property. The property is supported by all popular browsers (IE 7+, Firefox 1+, Safari 2+, Opera 9.2+), except, of course, Internet Explorer 6.

However, there is a workaround for IE6 and below. Notice that, as of version 8, Internet Explorer no longer supports Microsoft’s proprietary dynamic properties (MSDN IE Blog “Ending Expressions” ), also known as CSS expressions, so the IE6 bugfix will not affect newer IE versions. Dynamic properties, which allow you to use JavaScript logic such as control structures and mathematical computations, are discussed by Web developer Svend Tofte in the context of solving the “max-width” issue in Internet Explorer browsers. One can limit the width of the #content-block in the following example (www.svendtofte.com):

#content { 
max-width: 30em; 
width: expression( 
document.body.clientWidth > (500/12) * 
parseInt(document.body.currentStyle.fontSize)? 
"30em": 
"auto" ); 
} 

The user’s font-size settings – in points (pt) – are checked against the body’s width. Tofte determined, arbitrarily based on experimentation, that at 500 pixels the default 12-point font gets wider than 30 ems, which is what his layout width is set to.

Working backwards, if the body’s width is greater than the ratio of 500 pixels to 12 points multiplied by the user’s font setting, then you set the width of the element to a maximum of 30 ems; otherwise, you let it adjust its width automatically (hence the “auto”).

The downside of this technique is that, because dynamic properties are not included in W3C’s CSS 2 specifications, it invalidates your CSS. But depending on your situation, that may be a small price to pay for offering users of what is still one of the most popular browsers on the market support for liquid layouts with minimum and maximum widths.

The Clearleft website is an example of a fluid-width layout. The two images above show the website at a width of 1280 pixels and at 800 pixels. Notice how the content area adjusts the “We make websites better” slogan, wrapping it to three lines at 800 pixels and to only two lines at 1280 pixels

The Clearleft website is an example of a fluid-width layout. The two images above show the website at a width of 1280 pixels and at 800 pixels. Notice how the content area adjusts the “We make websites better“ slogan, wrapping it to three lines at 800 pixels and to only two lines at 1280 pixels.

Finally, let’s code a simple, pure two-column fluid layout, using the same HTML structure as the one in the fixed-layout example. Note again that you would need to use some kinbrowser reset to ensure a cross-browser presentation of the layout.

#container { 
margin: 0 auto; 
width: 75%; 
} 
#header { 
width: 100%; 
} 
#content { 
width: 60%; 
float: left; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 
#sidebar { 
width: 40%; 
float: right; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 

Here is a fluid layout tested in two Web browsers, one with a width of 1280 pixels, and the other with a width of 800 pixels, with the container width set to 75% of the browser’s view port.

#footer { 
width:100%; 
clear:both; 
} 

To determine the optimal width for a liquid layout, it is reasonable to use “width: auto” or any percentage value to make sure that the layout takes up the available width of the browser window automatically. For a minimum width, you could use a pixel value (like 760px); this lower limit could be used for all fluid layouts, so that the content remains readable even at the smallest screen resolution. For the maximum width, common practice is to use an em value (like 90em), so that the text width doesn’t get out of control but remains constant at various screen resolutions. A pleasant side effect: the maximum width is scaled according to the font size of the browser.

When implementing fluid layouts, use percentage values for the margins and padding of text elements (relative to the view port’s width, of course), so that when the window is resized, the margins and padding adjust, keeping the proportions consistent and their size flexible. This technique has been called “concertina padding” a term coined by Richard Rutter (“Web Standards Group: Ten Questions for Richard Rutter”, webstandardsgroup.org). When the page is resized, the margins and padding resize as well, keeping the growth of the content block in check, as well as the length of the text lines.

Fluid Grid Layouts

Grid-based design is a manifestation of order and precision. Essentially, grids allow for a strategic and systematic organization of typography and design elements, using alignment, symmetry and proper spacing; they contribute to creating designs that are pleasing to read and easy to scan. Grid layouts can be implemented in various layout types, but designers often assume that flexible layouts in particular are difficult or impossible to pair with traditional grid systems. That is not necessarily the case.

Essentially, a fluid grid layout can be created through a smart use of DIV layers, percentages and very simple math. The idea comes from Ethan Marcotte (Fluid Grids, www.alistapart.com), who realized that “if we could treat font sizes not as pixels, but as proportions measured against their container, we could do the same with the different elements draped across our grid”. His basic idea is to use relative units, namely percentages, and a simple division formula to find the equivalents of pixel widths that would normally be used for fixed-width design. Because em units in typography are all about context, other elements in the overall layout could be considered the same. As Ethan points out, “this will allow us to convert our design’s pixel-based widths into percentages, and keep the proportions of our grid intact as it resizes”.

A classic way to calculate proportion is to divide the font size of a given element in pixels by the font size of its container (that is, its context). As a result, we get the desired proportion, expressed in relative, em- or percentage-friendly terms. We get a quite obvious yet very helpful formula: target ÷ context = result.

Now, if we apply this formula to a design, we should end up with a solid fluid layout. However, we actually want a grid layout, so we start out by creating a well-defined fixed-width grid with seven columns of 124 pixels each, separated by 20 pixel-wide gutters, all of which adds up to a width of 988 pixels.

Let’s assume now that we have a 700 pixel-width <h1> element in our layout (which spans five columns and four gutters between them: 5 * 124 pixels + 4 * 20 pixels = 700 pixels). This element should be a block element and should be centered in the layout (which means having the overall horizontal margin of 288 pixels, 144 pixels on the left side and 144 pixels on the right side).

To calculate the width of <h1> in relative units, we simply divide 700 pixels (the target) by 988 pixels (the context), giving us 700 ÷ 988 = 0.7085. 0.7085 translates to 70.85%, which we can put directly in our style sheet:

h1 { 
width: 70.85%; /* 700px / 988px = 0.7085 */ 
} 

Of course, we also need to take care of the margins. Because the left margin is supposed to be 144 pixels (the target), we can again apply our formula to derive its relative width in the container (the context): 144 ÷ 988 = 0.14575, which translates to 14.575%. Finally, we get:

h1 { 
margin-left: 14.575%; /* 144px / 988px = 0.14575 */ 
width: 70.85%; /* 700px / 988px = 0.7085 */ 
} 

A simple grid layout with a title, information and large content block.

What remains is to apply this formula the same way to all layout elements, and we will end up with a solid, flexible, fluid grid. This is a very easy -concept and a much more efficient way to handle proportions in fluid -design. With this technique, a designer doesn’t have the excuse that proportions can-not be maintained or that they ruin the aesthetic appeal of their layouts.

Designers determine the length of margins in different ways. One way is to calculate the percentages of the margins (in this case, 20 pixels ÷ 880 pixels). Another is to set fixed margins or, as in our example, hard-code them as 20 pixels.

Each method has its pros and cons. With percentage margins, the designer risks making the margins too wide in very large screen resolutions but probably achieves better proportion. Fixed margins may cause slight imperfections in the proportions but guarantee that the spacing will look right no matter what the screen size is.

Adaptive Fluid (Liquid) Layouts

A common problem with fluid designs is that, even though they adapt to many screen resolutions, if the resolution is too small (such as on a phone or PDA) or incredibly large, things start to look a bit funny. For example, a three-column layout would look very cluttered on a PDA screen whose resolution is only 240 pixels wide. On the other hand, if the “min-width” property is used, the layout may contain a horizontal scroll bar and look unreadable.

To address this problem, we can use a technique that involves adapting content to specific ranges of screen resolutions. This is where the name “adaptive fluid layout” comes from. We can create slightly different custom layouts for resolutions that are 640 to 800 pixels, 320 to 640 pixels, 240 to 320 pixels and 240 pixels and below, respectively. Likewise, custom adjustments could be made for screen resolutions that are 800 to 1024 pixels, 1024 to 1280 pixels and 1280 pixels and up, respectively.

The benefits are obvious: the designer is able to leverage a layout’s look at different resolutions with greater accuracy. The tiniest and largest resolutions can be handled perfectly, while better adhering to design principles of spacing and balance, no matter what platform the design is being viewed on.

To create this type of layout, we need two things: separate style sheets for every range of screen resolutions, and a way of determining a user’s screen resolution. The first step is to create a set of alternative layout files. For example, one file could be called narrow.css and would be tailored to very narrow resolutions. Another could be normal.css and would apply to conventional computer screen resolutions, and a third could be wide.css and would handle unusually large resolutions.

We can then use JavaScript to make some simple alterations depending on the preset style sheets: for example, using Kevin Hale’s “Dynamic Resolution-Dependent Layout Technique” (www.particletree.com) or Marc Van Den Dobblesteen’s “Switchy McLayout” (www.alistapart.com). Declarations of all the style sheets and the JavaScript file are then put in the header, just like in any other type of layout.

<!-- Narrow style sheet --> 
<link rel="alternate stylesheet" type="text/css" href="css/ narrow.css" title="narrow" /> 
<!-- Default style sheet --> 
<link rel="stylesheet" type="text/css" href="css/normal.css" title="default" /> 
<!-- Wide style sheet --> 
<link rel="alternate stylesheet" type="text/css" href="css/wide.css" title="wide" /> 
<!-- Included JavaScript to switch style sheets --> 
<script src="scripts/dynamiclayout.js" type="text/ javascript"></script> 

Notice the title attribute in all three links to the style sheets: “narrow”, “default” and “wide”. Taking a closer look at the DynamicLayout() function in the JavaScript source, we can see that it is quite easy to customize which style sheet is called according to each title attribute. We can also see how to change the pixel widths accordingly.

function dynamicLayout(){ 
var browserWidth = getBrowserWidth(); 
// Narrow CSS rules 
if (browserWidth < 640) 
changeLayout("narrow") 
} 
// Normal (default) CSS rules 
if ((browserWidth >= 640) && (browserWidth <= 960))} 
changeLayout("default"); 
} 
// Wide CSS rules 
if (browserWidth > 960){ 
changeLayout("wide"); 
} 
} 

Richard Rutter’s variable fixed-width layout uses JavaScript to automatically scale the layout, including the typography, on the fly. Viewed at 1280 pixels, the layout is a four-column layout, but shrunk down to 850 pixels (as seen in the view port), the layout automatically becomes a three-column layout, with the fourth-column shifting down.

In the above image, you can see a demonstration of Switchy McLayout viewed at different Web browser sizes. The layout automatically adjusts as you resize the browser.

Notice that because adaptive fluid layouts rely on JavaScript, they require users to have JavaScript enabled so that it can detect the monitor’s resolution and serve the appropriate style sheet.

“Variable fixed-width layout” is a similar technique developed by Richard Rutter, based on Simon Collison’s width-based layout (which he discusses in the article “Redesign Notes 1: Width-Based Layout”, colly.com). As the screen resizes, so does the layout and typography. The change in layout size happens in real time, so if you were to resize your Web browser, the layout would adapt to your new size.

As pointed out above, a common problem with fluid layouts is that the text gets either so stretched or squished that the layout loses readability. Very narrow screens seem to create the biggest problem by causing big gaps in the text, but either extreme can frustrate users equally. Max-width and min-width are possible solutions, but when these properties are applied, the layout simply reverts to a partially fixed-width layout, and we lose the overall flexibility. Tinned Fruit’s text-zooming technique (tinnedfruit.com) is based on a JavaScript that automatically resizes text based on the width of the user’s screen. As the screen gets wider, the text gets larger. Likewise, as the screen gets thinner, the text gets smaller. In addition to this basic functionality, a designer can set a maximum and minimum text size so that the user never sees any odd-sized text. Furthermore, the designer can choose which elements should and should not be affected by the text zoom.

You can add the text-zooming JavaScript to a Web page externally. Below the external script line, simply insert the following code, modified as necessary:

<script type="text/javascript"> 
var contentZoom = new TextZoom( 
"Content", // Reference element 
"Content", // Target element 
0.22, // Zoom ratio 
70, // Minimum font size (%) 
130); // Maximum font size (%) 
addLoadEvent(textZoomInit); 
</script> 

Text-zoom technique: here is a portion of the maximized page (large width) that displays larger text.

Text-zoom technique: the same page as above, except minimized to about 700 pixels in width. The text is resized along with the browser. Notice that the text in the navigation at the top is not resized.

A similar technique was suggested by Soh Tanaka in his article “Smart Columns with CSS and jQuery” (www.sohtanaka.com). The technique is based on a script that alters the width of DIVs for the best viewing experience, and it also determines how many columns can be viewed across the page in the browser’s current size. The script removes any left-over white space from the ends of columns (which may have been caused by the browser’s width) and then redistributes it evenly throughout the columns using jQuery. The technique is perfect for users who resize their browsers, and does not simply treat browsers indiscriminately: a good example of an adaptive fluid layout.

Elastic (Zoomable) Layouts

When viewing a website with a fluid layout, the content can get so wide that the text becomes difficult to read. To improve readability, designers tend to limit the maximum width of a layout using CSS properties. An elastic (or zoomable) layout is a different approach that achieves the same goal; the basic idea is that designers adjust the width of the layout based on the user’s font size rather than the browser’s view port.

A pixel is an unscalable dot on a computer screen, whereas an em is a square unit of font size. Font sizes vary, and the em is a relative unit that adjusts to users’ text-size preferences (Elastic Design, www.alistapart.com). Consequently, designers size fonts in em units relative to the font-size value of their parent elements. By using ems for both layout blocks and text elements, designers are able to make a Web layout scale consistently, maintain optimal line length for the body copy and create realistic zoom effects. The result: when the user increases the font size, the layout stretches automatically, just as you would expect from an elastic object.

Because the layout width doesn’t depend on the browser’s view port, elastic layouts behave similarly to fixed-width layouts, and they also inherit their advantages and disadvantages. A major increase in the browser’s font size can make the layout explode in width and height, making the page completely unusable and unreadable. However, this will rarely happen, because a three-time increase in font size is not very common (especially if the designer uses a large enough font size as the base line for text elements).

As with fluid layouts, one of the most difficult things to grasp when starting out with elastic layouts is the math involved in calculating the proper em values. To simplify the conversion from pixels to ems, you can set the base value of the body’s font size to 0.625 em, or 62.5% (because the default font size of most browsers is 16 pixels⁴, and 10 pixels is exactly 62.5% of 16 pixels), which comes out to 10 pixels, making the calculation of the font size of child elements easier. For example, by setting the font size in the main body area to 0.625 em, you can set a DIV container that should be 960 pixels in width to 96 em; and so a <p> element there whose font size would otherwise be 12 pixels would now be 1.2 em.

One issue with elastic layouts, or layouts whose widths are adjusted based on font sizes, is the presentation of multimedia content, such as images and Flash objects. This adds complexity to elastic layouts, because in order for all elements in the layout to maintain their proportion, they must scale as the font size increases. Elastic layouts sometimes allow for all of their elements to scale; in other words, images will scale up or down in proportion to the layout, depending on the user’s settings.

Of course, this can be done by giving images percentage-based width and height property values, such as <img width="80%" height="80%" alt="Image" />. Remember, though, that scaling up images with very small resolutions using percentage values will decrease their quality, because the browser would perform a “simulated” zoom, resulting in pixellated and blurry images. Besides, the browser would load the entire (large) images from the server and rescale them, thus increasing the server load and delaying the page loading time. Therefore, most designers always use absolute pixel values for images.

Another solution, described in Harvey Kane’s article “Automatic Magazine Layout” (www.alistapart.com) requires some math and PHP. The title derives from how images are displayed in magazines: organized and always perfectly aligned. Consider the following PHP script:

# include the class file 
require_once('magazinelayout.class.php'); 
# Define the width for the output area (pixels) 
$width = 600; 
# Define padding around each image; this *must* be included 
# in your style sheet (pixels) 
$padding = 3; 
# Define your template for outputting images 
# (Don’t forget to escape the &) 
$template = '<img src="image.php?size=[size]&file=[image]" 
alt="Screenshot" />'; 
# create a new instance of the class 
$mag = new magazinelayout($width,$padding,$template); 
# Add the images in any order 
$mag->addImage( 'landscape1.jpg' ); 
$mag->addImage( 'portrait1.jpg' ); 
$mag->addImage( 'landscape2.jpg' ); 
# display the output 
echo $mag->getHtml(); 

We can pre-define the width that we’d like our entire magazine-inspired image layout to render as. So, if we can determine the user’s browser width, we can figure out how wide our image layout should be. This is easy enough, because we’ve already done it with our second technique: Fluid layouts with adaptive content. In his script, Kevin Hale uses a method called getBrowserWidth(). You can get an in-depth look at the code for this method in his article.

If we can use this method to retrieve the browser’s width as a number, then we can use that number to find the pixel width of our content area (or whatever other area these images are going to be placed in). Let’s say we’d like to put the images in our content area, which is set to a 70% width. Using simple math, we just need to figure out how many pixels is 70% of the browser’s width.

Pixel width = Percentage of Content Area * Browser Width 
$width = 0.70 * getBrowserWidth(); 

This is, of course, pretty basic math, and it is a pretty basic solution for dealing with images in fluid layouts, once the initial PHP script is set up. Adjust the PHP script to automatically find the pixel width of the images, and you’ve got a great way of dealing with images, or any other content that has a set width, in a fluid layout.

The main advantage of the elastic layout is its ability to always keep the proportions of design elements, ensuring proper readability and positioning. Elastic layouts are often the first choice for designers who want a compromise between fluid and fixed designs; the pros of each are found in elastic layouts. However, this layout type is more difficult to implement, and a lot of savvy and testing is often needed to get the layout right for most users.

Let’s try a simple two-column elastic layout using the same HTML structure we used before. If we know that 1 em equals 16 pixels, then a width of 960 pixels equals 60 em. The left column at 600 pixels translates to 37.5 em, and the right column at 360 pixels translates to 22.5 em. To make it easier, here’s the formula for calculating widths: 1 em ÷ 16 px * (width in pixels) = em equivalent.

#container { 
width: 60em; 
} 
#header { 
width: 60em; 
} 
#leftCol { 
width: 37.5em; 
float: left; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 
#rightCol { 
width: 22.5em; 
float: right; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
} 
#footer { 
width: 60em; 
clear: both; } 

The design community is divided in a heated disagreement about the viability of flexible layouts. The new generation of Web browsers – Firefox 3+, Opera 9.5+ and Internet Explorer 7+ – comes with a feature that seems will save Web developers a lot of work in future, namely the full-page zoom.

Instead of simply increasing and decreasing the font size of a website, browsers now enable users to literally scale the rendered layout, including visuals and background images. The whole design layout is scaled proportionally according to a set zoom factor, with all elements of a page’s layout expanding equally. Consequently, every fixed pixel-based layout becomes “scalable”; content always remains within the layout area it is supposed to be in, and there is no chance of boxes overlapping each other, as we saw in previous generations of Web browsers. Intuitively, this leads to the conclusion that elastic layouts will become obsolete and will have outlived their purpose, because they achieve the same effect with counter-intuitive CSS code.

However, this is not true. As Zoe Mickley Gillenwater points out ( “Why Browser Zoom Shouldn’t Kill Flexible Layouts”, www.zomigi.com), if you offer users a fixed-width layout with page zoom, they will sometimes see different number of characters per line than what you intended (for example, some people may increase the size because of vision problems).

It is also harder to preserve design proportions, because variable text sizes make it hard to predict where content will be displayed on a fixed-width page. Besides, while page zoom increases (and decreases) the overall layout of the website, in some situations it doesn’t make sense to zoom in on a logo or icon. On the other hand, it may make sense to enable users to scale only the content area or certain layout elements, which would be impossible with the browser’s zoom. And of course, all of the shortcomings of the pixel-based layout, including the horizontal scroll bar and excessive white space, still hold. The bottom line is, page zoom is helpful for users, but it is not a silver bullet for developers.

Hybrid Layouts

In practice, designers usually try to come up with the right mix of fixed-width, liquid and elastic layout elements to offer users the advantages of each, while minimizing the shortcomings of each as much as possible.

For instance, it has become a common practice to use em units for the content area (thus ensuring optimal line length and text scaling in Internet Explorer 6) and pixel units for the sidebar (because the sidebar often contains fixed-size ad banners that make this solution sensible). Another related technique is to have a fluid content area with “min-width” and “max-width” CSS attributes instead of the elastic element, making it possible for users to adjust the line length of the content block according to their personal preferences.

Less popular, yet still interesting, is the Jello-liquid layout (“Jello: A Different Liquid Layout”, www.uwmike.com). This technique is intended to slow down the proportional growth of a flexible layout so that its content area doesn’t become unusable. So, a fluid layout that has a width of 960 pixels when viewed in a browser whose view port is 1024 * 768 (960 ÷ 1024 = 0.9375) would not have a width of 1350 pixels when viewed in a browser whose view port is 1440 * 900 (1440 ÷ 1350 = 0.9375), but would have a smaller width instead. To achieve this effect, a large portion of the layout is fixed using pixel units, while the rest is defined with percentage values relative to the view port’s width. The smaller the fixed portion of the layout, the better the layout stretches with the growing view port: simple and clever.

Another interesting approach is the fluid elastic layout, which combines both liquid and elastic elements. The idea here is to set “min-width” and “max-width” for an em-based layout in percentage units (in essence, giving you the ability to limit rescaling to a certain extent by taking into account the view port’s size). By setting maximum and minimum widths, the text scales to a certain point and then stops. The layout remains fluid because it automatically adapts to the user’s view port, yet it is also elastic because the width of the columns is “scaled” automatically when the browser window is resized or the font size changes.

In the following example, we set the “max-width” CSS property for the container and columns. This limits the scaling of the layout to 100% of the browser’s view port. Again, “max-width” is not supported in older versions of IE, so we have to implement a workaround for IE 6 and below (not shown in the following example).

#container { 
width: 60em; 
max-width: 100%; 
} 
#header { 
background-color: #cccccc; 
width:60em; 
max-width:100%; 
} 
#leftCol { 
width:37.5em; 
float:left; 
display: inline; /* IE 5/6 Doubled Float-Margin Bug */ 
max-width:62.5%; 
} 
#rightCol { 
width:22.5em; 
float:right; 
max-width:37.5%; 
} 
#footer { 
width:60em; 
max-width:100%; 
clear:both; 
} 

Which Layout Is Right For Your Website?

The question of optimal layout doesn’t have a single answer. Depending on the context, time constraints and designer’s skills, each layout type has its purpose. A fixed-width approach usually works best for advanced visual layouts with heavy graphics (such as for entertainment, promotional and Flash-based websites, but sometimes also portfolios) because the images can be positioned more precisely, resulting in a more predictable and less error-prone design. Designers of such layouts need to consider the profile of the average user to make sure that the layout’s width is not too narrow or wide but remains usable across various browser view ports. Coding fixed-width layouts is also more straightforward and intuitive, as one doesn’t need to consider the relationship and proportions between elements.

While some designers strive for cross-browser pixel perfection, proponents of fluid designs do not think that layouts have to look identical across all platforms and screen resolutions. If this reflects your point of view, you may want to consider fluid layouts for your designs. These layouts are more time-consuming and less straightforward to develop, and they can create a risky and unpredictable environment, but they allow users to adjust layouts to their personal preferences. Liquid layouts usually have higher production costs but significantly lower maintenance costs than fixed-width layouts, and so provide a solid foundation for flexible, cross-resolution websites. Designers need to make sure that content blocks have the proper line length and should use the “min-width” and max-width“ CSS properties if necessary.

Still can’t decide? An elastic or partially elastic design is another option. When implemented correctly, elastic layouts bring a more predictable yet still flexible quality to layouts. Because elastic elements depend on font size (and not the browser’s view port), they allow designers to “freeze” proportions between layout blocks, ensuring balance between elements and good readability. In particular, because optimal readability (while also important in fixed-width layouts) is more critical on text-heavy websites, flexible layouts are more often used for magazines, online shops, blogs and the like. A smart use of the fluid grid can create an adaptable layout whose proportions remain faithful to the classic rules of graphic design.

In practice, designers often create an elastic layout when they use ems for typography and containers and a smart mix of percentages and pixel widths for the rest of the layout elements. These and similar hybrid layouts are most widely used in practice, reflecting designers’ attempts to find the best solution for each situation.

To conclude, it’s worth mentioning that with mobile phones, netbooks and game consoles becoming viable alternatives for Web browsing, smaller (and also bigger) resolutions are becoming more important and need to be carefully considered. For such platforms, dynamic resolution-dependent techniques may turn out to be useful and even necessary extensions to your layout type of choice. Adaptive layouts, though requiring more time to create, can handle unusually small or large screen resolutions with a bit of manual customization, helping the designer deliver the most preferred results to the most users. With the growing variety of screen widths, it’s only a matter of time before these techniques become essential.

—

1. As screen resolutions increase with high-resolution monitors, users generally tend to avoid browsing in full-screen mode. In many cases, an application is running beside the browsing area (such as a Twitter app, RSS feed reader or IM client), while the browser window itself sports a variety of extensions. See also “50.4% of respondents maximize windows”
   (www.456bereastreet.com).
2. Of course, many end users do not know that they can resize the browser to adjust the line length, but that is a topic for another discussion.
3. Of course, it depends on the designer’s ability to select reasonable width values for containers or to use more exotic numerical values to calculate the width of the layout’s elements. For the record, according to W3C’s specifications, using real number values in CSS (such as 82.345%) is okay, but you cannot be sure that it will be rounded and rendered identically in all modern browsers, which is why integer values are often preferred.
4. 16 pixels is a widely adopted default browser font size, but some people may change it or have the dpi on their machines set to 120 instead of 96, which would make all of the text on their system bigger.

← User Interface Design in Modern Web ApplicationsTOCThe Art and Science of CSS-Layouts (2/2) →