Project Management

Working toward more realistic design goals

Web designers go to great lengths to ensure uniform page rendering, employing all manner of CSS code hacks, browser detection scripts, and other tricks and techniques. Is it time to rethink design expectations?

This article originally appeared in the Design and Usability Tactics e-newsletter. Click here to subscribe automatically.

Web designers typically conceive of a page design and then go to great lengths to implement that design and present each site visitor with an identical page rendering, regardless of the visitor's browser or platform. To achieve this goal of uniform page rendering, designers often employ all manner of CSS code hacks, browser detection scripts, and other tricks and techniques. But maybe it's time to reevaluate this approach and question the practicality and appropriateness of the expectation that a Web page should look the same to each visitor.

Acknowledging the differences

Web page rendering differences are an inescapable fact. Nowadays, you can view Web pages on monitors, TVs, PDAs, and cell phones. No Web page can look the same on such a wide range of output devices. In comparison to such major form factor differences, routine browser compatibility issues seem almost insignificant.

That's not to say that there aren't noticeable differences in page rendering between various browser brands and computer platforms and much bigger differences between standards-compliant browsers and noncompliant browsers. This is just a reminder to keep those browser differences in perspective.

Another factor to consider is how user preference settings affect page rendering in browsers. While it's true that the typical Web visitor never changes the default settings, a significant number of visitors customize those settings to suit their preferences. Sometimes, visitors change their browser preferences on a whim; but more commonly, browser preference changes are an attempt to accommodate a disability, such as low visual acuity, color blindness, and so on. Browser users can change their default text size; set their own foreground, background, and link colors; and enable or disable images, as well as adjust screen resolution and browser window size.

All these changes in viewing conditions can affect the page display, thus rendering it impossible to deliver identical page images to every Web visitor. Even if it were technically possible to override some or all of the differences in page rendering, it isn't appropriate to do so because that would inevitably interfere with visitors' ability to control their Web experience. In many cases, Web builders have legal obligations to conform to accessibility guidelines that allow and encourage visitors to adjust the page display.

So, if any given Web visitor might experience such dramatic differences in the page display, why do so many Web builders obsess over obliterating the relatively small differences in page rendering between normal browsers?

Getting stuck in a rut of rigidity

Sometimes designers forget that the original conception of the Web was a highly flexible document presentation medium. One of its key strengths was its ability to allow text and images to reflow dynamically, meaning that Web documents were no longer locked into the rigid confines of a printed page; instead, they were designed with the flexibility to automatically adapt to fit the size and proportions of a resizable viewing window.

When graphic designers first started adding visual enhancements to Web pages, they often didn't appreciate this unique feature. Most of these designers came from a print background, where designs are implemented by precisely controlling the page elements' size and position. Naturally, the designers tended to use the same approach when designing Web pages. The typical result was a page design based on a fixed-size element (such as a table or div) that floats within the browser window. The fixed-size element serves as a background on which all other page elements are placed, thus allowing the designer to control the size and position of those elements within a familiar context that is relatively unaffected by changes in the browser window size.

The fixed-size background element is still used as the basis for most Web pages today. This means the Web builder has to fight constantly to force the browser to do something that it wasn't designed to do, which is to display a static page image instead of reflowing text to fit the browser window.

I believe that the prevalence of Web page designs that rely on precisely controlling the size and placement of each page element is partly responsible for the unwillingness of Web builders to accept any variation in the page rendering in different browsers. I suspect that ego also comes into play, because any deviation from the preconceived page layout might seem like a failure of the designer's/builder's skills.

Keys to good Web design

The real purpose of design is to enhance communications by engaging the visitor and boosting the content's readability with visual clues, such as headings that stand out from the body text.

The key to good design is successfully handling the juxtaposition and proportion of the elements. For most designers, controlling juxtaposition and proportion means controlling exact position and size of page elements. But it's the relationships of the page elements that really matter, not their absolute size or position. Size and position are just tools that the designer uses to convey those relationships to the visitor.

It's easy to demonstrate that good design doesn't depend on absolute size and position. All you need to do is proportionally resize any decent page layout from most any media. A good basic design works at any size, from thumbnail to poster-size and beyond. Most good layouts will even survive nonproportional resizing without falling apart. The demonstration almost always works because it's the sequence and relative sizes of the page elements that make the design successful, not their exact size or page placement.

In theory, it shouldn't be too hard to apply this same concept to Web page design. Instead of resizing (zooming) the basic page design to fit different browser windows, the browser actually reflows the text and images. The reflow retains the sequence and relative sizes of the page elements, which preserves the most important design attributes. Allowing the page elements to float and flow within the browser window creates some challenges, but it also creates as many opportunities.

This isn't just a theoretical exercise; it's a tested and proven approach to Web design called liquid layout. Using a liquid layout successfully takes forethought and planning. But, most of all, it takes a willingness to give up tight control over the position of every page element and allow your page design to flex and flow on its own. It means thinking about your design in terms of its structure and flow, and defining key relationships between page elements instead of striving for pixel-precise control. (The parallels to structural markup and CSS styles are no coincidence.)

There are many advantages to taking a more flexible approach to Web page design. Once you accept that your page layout is a dynamic design that flows and changes to fit different browser windows, you quickly realize that your page doesn't necessarily have to look exactly the same in every browser window in order to look good. That enables you to embrace a range of acceptable rendering variations, which, in turn, makes it easier to attain the goal of producing pages that look good in the target browsers and remain legible in all browsers.

The more tolerant your page design is of browser variations, the less likely you are to need to resort to code hacks and other techniques for dealing with browser incompatibilities. (You may not be able to avoid hacks completely, but any reduction in hacks will make your code that much faster to develop and easier to maintain.) Finally, working with liquid layouts tends to encourage good coding practices, such as using structural markup with CSS styling.

Editor's Picks