Fluid layouts using percentages is probably a bad idea

In the last post, there was a discussion of "fluid" layouts which only briefly touched on the notion of what a fluid layout actually means. In the transition from a CSSless web development to CSS enhanced web development we gained a bunch of units of measure, which alters the possibilities for fluid layouts.

In the traditional sense, a fluid layout meant largely that you had to use either percentages on all your "columns" or you had a "fixed" navigation column with a unitless content column (often achieved by setting that column's width to 100% and let the browsers break it). While both of these concepts have their place, it remains to be seen that either of them represent the holy grail of fluid layouts.

In the first case, setting percentages for both columns, you have necessarily created a layout without any real attention to the content. The developer makes some necessary assumptions when laying out a page like: 25% of the screen for navigation and 75% for content. The first assumption is that 25% is an appropriate size for the navigation. The second assumption was that the browser will necessarily break the layout and save your design when it was too small.

The second problem relates to how designers used tables as hacks. A table cell, by default, has to contain its contents, there are no exceptions. That means that when the content exceeds the specified width, the width is ignored and the content is contained. So in reality, designers relied on their layouts breaking to save them.

The first problem is a little less obvious. When developers say that navigation should consume 25% of the screen, they make the decision based on what a normal person would see at 25%. However, the size of 25% varies wildly because of things like resolution, window size, etc. 25% of 800px might be what you're after, but 25% of 300px or 1200px might be too small or too big, respectively. The 25% has less to do with the actual content contained within and more about wishful thinking and a naive reliance on the browser gracefully breaking the layout.

Developers and designers recognizing the inherent flaws in setting things like navigation bars to widths using percentages shifted to the slightly more realistic fixed column fluid content block. This eliminated the variation of width problem and still kept the content "fluid". For table-hacks, there is not much of an alternative. Without delving into the complicated world of CSS, the best you could do was width="150".

The obvious problem here is that by setting a particular pixel width, you're just hoping that your content will fit appropriately. Again, it's wishful thinking on the part of the designers because when that troublesome end-user changes their font-size, and you're not using fixed fonts, the navigation bar all of sudden looks too narrow or too wide (depending on if they increased or decreased their font-size). All the time the designer spent with the rules of proportion is thrown out the window.

That is, until one realizes that there are CSS units that go beyond simple % and px.

The em

For example the em. The em is a relative unit of measure. It is roughly equivalent to the size of the capital letter M at the current font-size. This gives designers an extraordinary amount of control over the width of a column as related to the content of the column.

What that means is, say that the longest line of the navigation is the word "navigation", but setting the width of the navigation to 10em, you will necessarily contain the word navigation with room to spare (notice that all the letters are probably smaller than M). Furthermore, a nasty user who changes their font-size will always see the same proportional size of the navigation bar.

By applying em, you can create a hyper-fluid page. The page's content will be fluid to screen size, *cough* and line-length *cough*, and the navigation bar (or any other bar) will be fluid to font-size and have some designer specified relationship to the content the bar contains. The best of all worlds.

Nevertheless, for most developer's the biggest hurdle is becoming proficient in recognizing when to use em and when to use other units of measure. A topic for another time.