One of the first things our layout will have to deal with is window size. Designs too wide for the window frustrate users as they scroll left and right, but designs too narrow can also be frustrating, as they string boxes out vertically, when they would fit on screen. What to do, what to do?

Some designer’s deal with this by choosing to submit to the lesser evil. The frustration of having to scroll horizontally is higher than the frustration of having to scroll vertically, so they fix the width of their design. They choose a width that will fit within the vast majority (75-80%) of their visitors’ windows. What width they choose depends upon their intended audience: if they make it too narrow, the frustration of those with wider windows grows, and if they make it too wide, the number frustrated horizontal scrollers improves.

There’s no perfect number, so they try to balance them as best they can. So, how would someone practicing Reactive Layout approach this problem?

We would start by reviewing the principles, looking to apply them. “The web is not paper” tells us window sizes can change, but also that layout can change, as well. Unlike with paper, the web does not force us to stay with one layout, though we can if we want. “The Web is a two-way medium” gives us another hint: the user’s browser can help us by telling us what the window size is. We don’t have that information now, but we can have it for the asking, in multiple ways. “Unity is not unison” gives us another hint — maybe every browser doesn’t need to see the exact same layout to make the site work. And the Hippocratic-sounding “Do No Harm,” while it doesn’t directly help us here, it constantly reminds us that whatever we do shouldn’t break things for others.

Stretching Exercises

One way we can approach the problem is to make our design stretch with the window. The way to do this is to convert all horizontal measurements to percentages of the window width. For example:

body { width: 90%; margin 10px auto; }

This results in the body being centered in the window. If the window width is 1200px, then the body is 1080px wide, if the window width is 900px, then the body is 810px wide. The content for the page is then flowed inside this container, and the page gets longer when the window narrows. Boxes placed inside the body should also be sized as percentages to preserve their elasticity:

#menu { width: 25%; padding: 0 2%; float: left; }
#main { width: 66.5%; padding: 0 2%; float: left; }

This would result in two boxes placed side-by-side, and they would stretch with the window. (Note the percentages add up to 99.5%, not 100%. This was intentional, though the fraction itself is arbitary. It’s necessary because of rounding errors that can happen when working in percentages. When sizing a box by percentages, remember that the final size of the box will be in whole pixels, no matter what the math works out to. If the browser rounds up, the box may become a pixel wider than you expected, and that would mean there wouldn’t be room for the second box, and the design would break. If you deliberately make your percentages add up to less than 100%, you avoid this sort of breakage.)

The advantage of using this method is simplicity; you have only one layout to work with and tune. But the disadvantage of this method is that it can create extremely long reading lines. And while this isn’t fatal, you can do something to limit the damage:

#main {
width: 66.5%;
padding: 0 2%;
float: left;
column-width: 13em !important;
column-gap: 1em !important;
column-rule: 1px dotted black !important;
-moz-column-width: 13em;
-moz-column-gap: 1em;
-moz-column-rule: 1px dotted black;
-webkit-column-width: 13em;
-webkit-column-gap: 1em;
-webkit-column-rule: 1px dotted black;
}

This code takes advantage of the column-flow rules in CSS3. WebKit and Mozilla based browsers will recognize the vendor-specific rules, but as the specification gets approved, more browsers will recognize the standard-compliant rules at the front. By placing those rules before the vendor-specific ones and marking them as important, we future-proof the CSS, indicating that the standards-based interpretation should be used, when available. Not all browsers support them, but those that don’t won’t be adversely affected by these rules (“Do No Harm”). And those browsers that do support these rules will take advantage of the extra room to create more columns (“Unity is not unison”).

This isn’t a solution for every layout, however. Long stories will be broken into two columns, with each column possibly flowing outside of the window, causing even more vertical scrolling. I prefer to use this particular approach only when I’m fairly certain the text will be contained within a single window, but if you decide to use it even when there is a potential for longer stories, be kind enough to your readers to place a link at the bottom of the story’s block that will automatically take them back to the top of the story. Saves them scroll time.

Follow The Script

A second technique you can apply here is javascript-based. It was given the name “Switchy McLayout” by Mark van den Dobbelsteen when he wrote about it for A List Apart and I kept the name as a nod to him when I wrote my MooTools plugin.

Follow the links for details, but the basic idea is to read the window width with Javascript (The Web is a Two-Way Medium) and attach a class name to the body tag based on the width. That class name can be used in the CSS to change the page layout (Unity is not Unison — narrower pages use fewer columns, so the main content doesn’t get squished).

Not everyone has Javascript enabled, so the proper way to implement this is to select a “default” state (Do No Harm). Then we use the classes and the specificity rules to make changes in the default layout like this sample from a past layout of mine:

#sidebar {
display: block;
clear: both;
float: none;
padding: 0 0.5em;
border: none;
}
body.wide #sidebar {
width: 23%;
float: right;
padding: 0 0.5em;
border-left: 1px dotted #999;
}

This describes the sidebar as a block that displays where it falls in the regular flow of the document unless the window is wide enough to support an extra column, when the sidebar will float out to the right edge instead.

The advantage to this approach is that it leverages the flexibility of CSS to provide multiple layouts for the same markup (see The CSS Zen Garden for hundreds of inspiring examples of just how much flexibility there is in CSS) and uses Javascript to determine which layout should be used.

Of course, no advantage goes unpaid for. Visitors with Javascript disabled get your default view. Of course, if you select the default view in accordance with the principle of “Do No Harm,” that in itself won’t be an issue. But a further disadvantage is the creation of multiple layouts. Even though you can limit this effort with proper forethought, it is still an effort. Is the extra effort worth giving a better, friendlier design to a portion of your audience? That’s a question only you can answer. My task is to tell you how to use it, you have to decide for yourself if you’ll use it.

Questioning The Media

A third approach to this is using media queries. Media queries are a Candidate Recommendation for part of CSS3, and are supported by some browsers (as of this writing, all current versions of the Big 4 support it, I believe). How do they work?

@media screen and (min-width: 800px){
#sidebar {
width: 23%;
float: right;
padding: 0 0.5em;
border-left: 1px dotted #999;
}
}

The style block above sets out style selectors and rules to be applied if the window is less than or equal to 800px. It basically does the same thing as the previous javascript example would do, if the threshold for the “wide” class was 800px.

The advantage of this technique is that it works even when Javascript is turned off. The disadvantage is that users of less-than-current browsers won’t see any styles inside the media queries. The odds are great that, for today at least, you’ll reach more visitors with Javascript than with media queries. But time is on the side of media queries, because while people who surf with Javascript turned off will probably always do so, people do upgrade their browsers, so eventually more people will be served by media queries than by Javascript.

Once again, you’ll have to weight the effort of this against the benefit to your visitors for yourself, but even if you decide not to do it for now, I’d recommend playing around a little with this code to get familiar with them. You will (eventually) find them useful, perhaps even indispensable. For one thing, they may be the most reliable way to target cell phones and PDA’s in your audience.