Not So Minimal: Dealing with common overflow problems

Dan Rubin, Designer

www.csszengarden.com/024

THE TITLE OF Not So Minimal raises the question, not as minimal as what? There is a history behind this design: Dan Rubin's first submission to the Zen Garden was created with a goal of maximum simplicity. Dubbed Grazay, the original design can be seen at www.superfluousbanter.org/projects/zengarden/grazay/zengarden-grazay.html.

With an intentionally light color scheme and typeface selection (FF DIN Condensed and Verdana), Rubin submitted Grazay (FIGURE 1). While recognizing the importance of good minimal design work, the Zen Garden was aiming to overcome the stigma of minimalism attached to CSS design. Rubin developed Grazay further with extra graphical embellishments, and it became Not so Minimal.

Figure 1. Dan Rubin's original Grazay shows how Not So Minimal evolved to become, well, not so minimal.

Content Overflow

One of the most common frustrations when building a CSS layout is the challenge of planning for the variable nature of the Web. Specifically, the problem is working with the predefined widths and heights of CSS when the amount of content is unknown ahead of time.

Inconsistent content length is simply the nature of the Web; pages may contain as little or as much content as necessary. Dynamic sites running software like a content management system (CMS) have the potential to insert variable-length content that can be abnormally short or incredibly long.

Unless content length is strictly enforced by the author or the CMSwhich is unrealistic in most casesany area with content liable to change must be tested for both short and long content lengths. Text-based content is much more unpredictable than images, since image sizes are fixed at predetermined dimensions and thus non-scalable, but this isn't a hard and fast rule. A CMS might insert more than one image, or the height may be variable, or any number of other factors may exist that would cause size differences.

Most browsers now provide the user with the ability to resize the text on the page, and those with less than 20/20 vision often rely on this. Larger font sizes may end up causing similar overlapping problems with the layout. Content areas that solve the problems of variable-length content will theoretically also avoid any further complications arising from larger font sizes, but short bits of text like navigation links are particularly susceptible. It's never a bad idea to make sure a page is robust enough to handle scaling up by 150 percent or more, because some users will be viewing with fonts that large.

Note

A further problem when working concurrently with standards-based design and CMS software is that many popular systems generate invalid markup mixed with legacy presentational tags. Styling a font tag is an exercise in futility, and the custom coding necessary to bring these systems up to speed has traditionally been out of reach of many budgets.

The situation is improving, however, and more recent CMS software does a much better job of generating valid XHTML/CSS out of the box. Popular open-source CMS packages include Drupal (www.drupal.org) and Mambo (www.mamboserver.com).

One way or another, it's highly likely that you will eventually have to deal with a content area that overflows, either horizontally or vertically. Telltale signs to look out for are overlapping content and big areas of content showing up further down the page than they should. The first is indicative of an absolute-positioning overflow problem; the second is indicative of floats that are too wide or high for the area they should sit within.

Float Overflow

The float attribute is technically not a layout tool. Floats were developed to give text the ability to wrap around inline elements, and were never intended for use as a full-blown layout method. We must use floats, though, for one simple reason: No other layout tool allows content to be cleared.

Tip

Eric Meyer has written extensively on the subject of clearing floats. Make sure not to miss "Containing Floats" (www.complexspiral.com/publications/containing-floats).

In its simplest form, the clear attribute and the concept of clearing might be described as an ability to tell elements not to begin before another element ends. The overflow problems of absolute positioning mostly stem from a lack of the ability to clear a positioned object.

But floats are imperfect and made doubly problematic by the problems many browsers add to the equation.

Tip

A method for clearing floats without a clearing element in the HTML is available. It involves a few non-intuitive hacks to get it cross-browser compatible, but it does work. See "How to Clear Floats Without Structural Markup" (www.positioniseverything.net/easyclearing.html).

Clearing Requires Markup

For clearing to work properly, you need at least two elements in your HTML: the one that gets the float, and an extra element to clear it. Two div elements might float left and right, respectively, but a third would then be necessary to clear them. Often it's possible to tap into elements that already existfor example, clearing a floated h3 with an otherwise unoccupied p.

But at times it becomes a necessary evil to drop an extra blank element into your markup for the specific purpose of clearing a float. If this is the case, we recommend using an all-purpose div and leaving the contents blank, like so:

 <div ></div> 

A clear value can then be applied to the class. It's ugly, but it works without adding too much extra meaningless structure to your HTML.

Floats Require Precision

If you fill a 1-gallon aquarium to the brim and then dump in a quart of sand, what happens? There isn't enough room for everything, and some of the water spills over the sides of course.

Floats have similar limitations, mostly involving horizontal overflow. If two floats that are 50 percent of the width of the screen each get positioned side by side, and one is given an extra margin of 100 pixels, the other will be squeezed out and drop below the first. Calculating the widths ahead of time is important.

But Microsoft Internet Explorer for Windows doesn't support the width and height attributes quite as the CSS specification recommends. What's supposed to happen is that an element with content wider than its width value will either reflow the content or, failing that, leave the element's width as is and allow the content to spill outside of its boundaries. The upshot is that the floats remain unaffected, even if the content starts overlapping other elements.

Internet Explorer, on the other hand, allows the width to expand as necessary. As soon as a float is even 1 pixel wider than it should be, it will squeeze out other floated elements (FIGURE 2). There are a few ways to address this problem.

Figure 2. If floated elements are too wide for the area they have been designated, one or more may be squeezed out and appear below the rest.

Make the Area Wider

If you have the ability to increase the area in which the float rests, often this will solve the problem. It's not an optimal solution, but it should be the first method to consider due to its relative ease of implementation.

Limit Content Width, Italics

If it's at all possible to ensure that content will not cause horizontal overflow, the problem is avoided. This is usually an unrealistic solution, because the problem wouldn't exist if the content weren't too wide to begin with.

One particularly silly bug to watch out for is content that appears to be the proper width but continues to cause problems, specifically in Internet Explorer for Windows. If you're experiencing this, and any text within the floated area is italicized, try removing the italics and see if that corrects the problem. Italicized text has the potential to cause horizontal overflow in Internet Explorer, and if simply turning it off solves the floating problem, you've found the culprit. No, text formatting shouldn't affect a layout this way, but there you have it.

Limit Content Overflow

We'll explore the overflow attribute in the next section on vertical overflow, but it's also possible to limit horizontal overflow using it. Solutions that use overflow this way are often inelegant, so we recommend exercising caution.

Absolute-Positioning Overflow

Problems with absolute positioning are usually problems with vertical overflow. The exceptions are instances where a positioned element has a certain width, and not enough area has been set aside to account for that width (FIGURE 3).

Figure 3. The 150-pixel-wide #linkList is too wide for the 100-pixel-wide area that has been allocated for it.

Vertical Overflow

Dealing with vertical overflow is much more common. The problem is simple: Unlike floated elements, absolutely positioned elements cannot be cleared in any way. Once positioning has been applied, the element is removed from the document flow and no longer influences elements surrounding it.

This issue often occurs when dealing with page footersa column that has been absolutely positioned may grow longer than other columns that are influencing the footer's placement. The positioned column will keep running vertically right over the top of the footer, and further (FIGURE 4). Unfortunately, there really is no foolproof solution; there are only work-arounds:

Figure 4. If the content area were shorter, the absolutely positioned sidebar of Not So Minimal would overlap the footer stripe.

Use Floats Instead

The most effective work-around is to use floats instead of absolute positioning, and to take advantage of the clearing ability they offer. This is not always possible, of course, but if a floated layout might work, it's worth exploring.

Design Around the Problem

Alternatively, it might be possible to grant the absolutely positioned element free range of the rest of the page, vertically speaking. If it overlaps the footer at the bottom of a page, redesigning the footer with a margin the width of the element might be one way out. When no elements are placed below the positioned element, there's nothing to overlap and thus no problem.

Limit Overflow

Instead of attempting to control content length, it's far more beneficial to explore the automatic overflow-control features built into CSS. The overflow attribute was theoretically built for precisely this reason, but it's not quite the silver bullet one might hope for. If you limit an element's height to 150px and set the overflow value to auto, the height is clipped to precisely 150 pixels and the user is given a scroll bar to view the content that happens to overflow past 150 pixels.

But too many scroll bars in one page quickly annoy viewers. Alternatively, setting the overflow value to hidden will completely hide all content that spills over the cutoff point. In most cases it's best not to conceal content this way, since hidden content is useless to the viewer, but in rare situations this may be precisely the overflow-handling method desired.

Script Your Way Out of Trouble

If you're not averse to using minimal JavaScript to complement your CSS, there are scripts to combat this problem. One of the Zen Garden contributors, Shaun Inman, has produced a useful method for clearing absolutely positioned elements similar to clearing a float. This script is available in "Absolute Clearance" (www.shauninman.com/mentary/past/absolute_clearance.php).

Use em Values Instead of px Values

This tip applies only if overlapping occurs when font size is increased; it won't fix overlapping in dynamic content areas. Absolutely positioning with the px unit is great for maximum control, but there's no flexibilityonce an element is positioned, that's where it stays. But by using em unit values for attributes like top and left, the element's position is slightly more flexible: It will adjust according to the user's font size. If stacked elements are given values in em units, as the bottom of one changes position so will the top of the next. It's an imprecise method, but it does work in many situations.

Design for the Overflow

The absolutely positioned left sidebar in Not So Minimal safely avoids the overflow dilemma because the content area on the right is much longer. Had the Zen Garden been a larger site with multiple pages of content, different pages may have featured a longer sidebar and pages with much shorter content. The overlapping previously shown in Figure 4 would have more than likely reared its ugly head and forced some extra thinking toward dealing with the overflow.

While technology concerns shouldn't drive design decisions, overflow is a significant problem when building larger sites. If you can avoid the problem simply by designing around it, the technical limitations of the techniques to deal with overflow won't seem so frustratingly inadequate.