Jeanne's World
   The Shoebox
       Bad Web Designer, No Cookie

Bad Web Designer, No Cookie:



Horizontal Scrolling Must Die!


This issue, we take up arms against that bane of the Web, pages consisting in their entirety of a hard-coded-width table - though regrettably without any hope of, by opposing, ending them.

WHY do people do this? Is it laziness? Is it stupidity? It's probably because they see everyone else doing it. God knows it's become almost impossible to avoid.


Here's how it happens: a designer wants to set a hard pixel width for a page. Normally, HTML flows to fit the size of the browser, so everything is visible without horizontal scrolling. Tables usually also follow this rule; the browser formats the table to the optimum width that will fit in the browser. However, a table can include a specific width in pixels. It's the only HTML method that allows specification of a pixel width for a block of text.

The hardcoded-width table gambit appeals to web designers who want to eliminate variables in their design, to try to force the page to look the same no matter how it's viewed. (For such designers, considerations of "how it's viewed" are usually limited to "how it's going to look in both browsers - Netscape and Explorer!".) These designers commonly come out of a page-layout background, so naturally they think in terms of defining a page size - analogous to the piece of paper their training has taught them to think of first - and then laying out fixed size elements in it.

Unfortunately, that approach produces web pages that are extremely fragile. The carefully-designed presentation falls apart all too easily.

The Horizontal Scrollbar Rears Its Ugly Head

The first problem arises when a visitor to the site is inconsiderate enough to prefer a window size smaller than the one the designer assumed as a minimum. This can happen for many reasons. One person may prefer a smaller font size, and narrow the browser window accordingly so they don't have to read uncomfortably long lines of text. Another may use a notebook computer that doesn't have a large screen. Still another may find it easier, when switching between applications, to use windows that don't take up the full screen.

What happens next is, considered as a user-interface problem, ugly. The browser window sprouts a horizontal scroll bar, and the visitor needs to scroll back and forth, back and forth, to read each line of text. It's much harder - physically harder - to read text like this than to read it normally: it's hard to keep your place on a line and impossible to scan entire lines for meaning while skimming. Most visitors won't bother; that handy Back button will come into play.

Even if the page contains little or no text, having to scroll in two dimensions is bothersome. The visitor must move the pointing device back and forth, back and forth, between the two scrollbars; it's hard to be confident that you've seen every option on the page. All in all, scanning such a page is a little like trying to read a magazine looking through a cardboard tube. (And it's hardly conducive to making a good impression with that carefully-designed layout.)

The Line Length Problem

Most research shows that a line length somewhere between 55 and 65 characters is optimal for reading on paper. Some designers misguidedly defend setting a hardcoded width on the grounds that they are ensuring an appropriate line length. But of course, since the visitor controls the font and size of text, setting a line width by specifying the number of pixels isn't possible. You can't calculate a pixel number from a number of characters unless you know what the font and size are, and unless you know the maximum display width - in a graphical browser, the window size - you have to work with. In HTML, you don't know these things; so you don't possess the context necessary to make an intelligent choice of pixel width. If you try:

The point here is that the visitor has already configured font, size, and width; these things are already set to what that person finds comfortable to read. A page can change the pixel width, possibly font, and possibly size, but has no control over screen resolution, window size, screen brightness and contrast, or the visitor's eyesight or personal preference, and no way of setting a character width for text lines. By changing some but not all of those factors, the designer creates a situation that by its nature will be suboptimal for reading. Some designers choose to compromise reading ease in the interest of a layout they find more aesthetically pleasing, but using such techniques supposedly to increase reading ease is madness.

The Vile Specter of Full-Page Tables

In the quest for layout control, web designers sometimes wrap the entire page in one giant table. You've seen this effect on sites that place an index in a column on the left, with the page content to the right: the page consists of a single two-column table.

The problem: current browsers must download the whole text content of a table before they can start to render it on screen. Anything that comes before a table on the page is displayed right away, but while the table downloads, the visitor is left staring at a blank screen - for anywhere between several seconds and a few minutes, depending on how much is in the table, how fast the connection is, and how clogged the web server might be.

It's easy to see what a bad idea it is to enclose an entire page in a table (particularly if the page is at all large), since if you do that, the window will remain blank the whole time the table is being downloaded and rendered, and that means the site will seem a lot slower than it needs to. Good web designers know this. But layout artists usually ignore it; since the concept of responsiveness, in the user-interface sense, is not relevant to design for paper, it's alien to their experience and not something they're taught about.

(I'm beginning to wander off the subject here, although this consideration is relevant to analyzing why graphic designers don't necessarily produce good web pages - they may be good-looking when static, but designing a web page is fundamentally a user-interface problem, and graphic design is only one part of user-interface design. Responsiveness, usability, robustness are all considerations that web designers must master, and graphic design won't help them there. But I was talking about tables. Excuse me.)


I'm not arguing against use of layout tables per se. I use tables for layout in many different ways, though I very rarely enclose a whole page in a single table, and never set a pixel width for a text table.

It's not a question of which tags and attributes are "good" or "bad"; it's a question of how they're used. Good design needs to take into account how a tag will be rendered on many different browsers, on different platforms, with different configurations, under different sets of user preferences; bad design ignores all this, and just throws in whatever will produce the desired visual result on the designer's own setup. Similar things can be said about almost any HTML construct. They all - with the possible exception of <blink> - have legitimate uses, but almost any of them can be used to destroy accessibility in the hands of a careless page author.

To sum up in the undiplomatic style typical of this space:

  1. Do not put the whole page into a table. Bad web designer, no cookie.
  2. Avoid making the assumption that all your visitors have the same browser, monitor, fonts, window size, and personal preferences you do. That way, your design will stay flexible under varying conditions, instead of degenerating into an ugly hash.
  3. Do not use a hardcoded table width for content that doesn't require it. (Be very careful of this if you use a graphical editor to create web pages. Some of them not only allow this, they force the practice on otherwise inoffensive pages. Bad authoring tool, no cookie.)

See the horizontal scrollbar? Toss your cookies.


Jeanne A. E. DeVoto jaed@jaedworks.com
Copyright © 1997 Jeanne A. E. DeVoto