Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Adding Complexity: Layout & Style Variations

Last updated Oct 17, 2003.

CSS is all about separating the look of the page out from the underlying structure and content within the HTML. But why stop there?

An idea that I've noticed popping up with growing frequency is that of pushing the idea of separation even further, and break the ties between the layout of the page and its formatting. By layout, I mean the visual structure of the page, the basic shapes that divide a page into two columns, and separate the header from the content area. By formatting, I mean all the visual decoration that isn't necessarily layout – things like your font formatting, colors, imagery, and the like. An example to illustrate:

Figure 1

Figure 1 Combining layout and formatting possibilities.

In each row, on the left we have the building blocks for a very simple layout. Both rows have the same layout. In the middle we have a series of styles and colors. When we mix them together, we get a complete design, on the right of each row. The basic layout stays the same, but the formatting styles lead to very different end results.

Why would you want this? In theory, it leads to practical mixing and matching of styles. If you have 6 layout variations – maybe a 2 column, a 3 column, and a few others – and you have 6 visually different ways of styling those layouts, you effectively get 36 templates for the price of 12.

This is a valuable idea to clients who require a bunch of templates at once, for re-use across various sections of a large site – or more commonly for the purposes of offering the finished templates as choices to end users of their application or product. Think content management systems of any stripe, including blogs and e-commerce.

However, after having worked on these types of templates for multiple clients, I've discovered that it's a challenging idea that sounds deceptively simple on paper, but ends up creating design problems, making it more difficult than it should be. While CSS might appear to lend itself to an idea like this, it rarely works quite the way you'd expect due to the design criteria and code constraints.

Basic Explanation

In one set of CSS files, you place only the basic style rules that define a layout. You're simply looking for a skeleton layout, with nothing more than simple positioning and box model properties defined: widths, padding, floats, and other CSS properties that affect the size and position of elements.

In another set of CSS files, you place all other style rules for the formatting and visual decoration of those basic layout blocks: fonts, colors, and so on.

Basic Problem

The real problem is evident when we start to consider how much separation between these two ideas we can actually achieve. Remember, first, that the separation of structure and presentation is a guiding principle built into the foundations of CSS. The separation of layout and formatting, on the other hand, is an idea we've come up with after the fact.

Consider borders. For our purposes, they are a bit tricky since they have properties that are both visual decoration (color and size) as well as specific widths that could potentially conflict with layout properties. One way to solve this is by placing border widths in the layout CSS file, and other border properties in the formatting CSS file.

Typographic spacing is another problem area. Within one layout it might be appropriate to have larger line-height value, but within another that same value doesn't make as much sense. Consider the following:

Figure 2

Figure 2 line-height problems.

In the example on the left, the wider column lends itself well to nicely spaced-out text. But in an alternative layout with the same line-height, the narrower column on the right looks very strange.

One of the biggest problems with this separation of layout and formatting happens when it comes time to deal with imagery. Beautiful, functional CSS designs rely on plenty of background images to work their magic. But images are not nearly as flexible as the CSS they complement.

Let's use a popular web design trick, the rounded corner, as an example of how this inflexibility can be a problem. Commonly in CSS, this is pulled off with two images used in conjunction to simulate the appearance of four rounded corners, one on top and one on the bottom.

Figure 3

Figure 3 A top and bottom image to simulate rounded corners.

This works great in any layout where the width of the images matches the width of the column they'll be sitting in. But let's say we've placed the appropriate background properties in our formatting CSS file, which is where they belong. When we combine this formatting file with a layout that has a completely different column width, all of a sudden our images don't fit anymore:

Figure 4

Figure 4 Rounded corner images break in a differently-sized column.

Whoops.

Not so Basic Problem

And finally, the big showstopper moment (drum roll, please)... The browsers. After you've built your 36 combinations, now you get to go and test them in, depending on your requirements, anywhere from four to a dozen or more browsers. A bit of math tells us that if we've got six browsers to check, and 36 combinations, that makes 216 different page refreshes, and we potentially have to fix every one if something went wrong.

Not only that, but let's say one of your layouts is misbehaving in Internet Explorer 5.5, so you go and correct it. Except you just fixed one layout/formatting combination, but broke all five of the others in the process. So you fix them. But now another combination doesn't work properly in Opera. So now you have to start all over again with the new problem, building fix upon fix into your style sheet. Refreshing all 216 times until somehow you find the magic balance, and dare not even sneeze lest the whole house of cards comes tumbling down.

Insanity? Oh yeah. I've been there. It's not fun.

Coping

So if we really want to pursue this idea (or your client read this article and figured it was still worth a shot [sorry!]) then how do we make it a bit easier to develop?

First of all, we need to acknowledge up front that 6 layout files and 6 formatting files will never work, for all the reasons I've outlined above. To start, pick one set as your masters – the layout files are the more practical choice as masters – and adapt the other set to suit. Build the master set as a foundation, browser-test it until it's rock-solid, and then don't touch it. Build the secondary set on top of it, so that any tweaks happen only in the secondary set, on an as-needed basis.

So instead of creating only one file for each of the 6 formatting styles, instead we'd build one file as a base and then others for each layout/formatting combination as tweaks are necessary, potentially leading to 30 or more formatting files in the end (plus the original 6 layout files).

That sounds a bit more complex, because there are more files involved, but individual, per-combination tweaks like this are the only way to make sense of the situation. Especially when it comes time to browser test, as the master set should not change, leading to less double- and triple-checking.

So let's say we have a formatting style called 'Red Sunrise', for example. We might start with a single file of common rules for that style that do not need per-combination tweaking. We would then build variations of it, one for each of the layout types as necessary, limited to only the minimum tweaks necessary to make each particular combination work.

The more astute of you may have realized by now that we might not really need those separate files; if they're simply minimal tweaks, we could identify each layout in the HTML with a unique id (say, applied to the body tag like so: <body id="two-column-left">) and then tap into that from the CSS to deliver the tweaks only to the layout that needs it:

#two-column-left #navigation {line-height: 2;}
#three-column-left #navigation {line-height: 1.5;}

And so on. If this will work within the constraints of your project, it might be a nice alternative way to deliver the initial goal of 12 files in total. But if not, there's no harm in creating secondary tweak files as needed.

Tweaks are Essential

If you decide to tackle a project of this nature, you'll quickly realize just how many pitfalls lie in pursuing this separation idea. If you only remember one thing from this article, the key point is this: realize in advance you must make per-combination tweaks to get this whole crazy system up and running, and compensate for that in your code as best fits the project.