Jeanne's WorldThe ShoeboxBad Web Designer, No Cookie|
Jeanne's WorldThe ShoeboxBad Web Designer, No Cookie |
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 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.)
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:
Visitors who prefer a significantly larger font (perhaps because their eyesight is poor, or because they use a high-density screen, or because they read on the web a lot and want to avoid eyestrain), and have their browser window set to a width that gives an optimal line length in this font, will be screwed, in that the fixed pixel width will force the line length to be shorter than optimal.
Visitors who prefer a smaller font (perhaps because they have excellent close eyesight, or because they have a low-density screen on which 8-point is quite readable), and have their browser set to a width that gives the optimal line length, are also screwed, because the fixed pixel width will give them lines that are too long (too many characters) to be comfortable to read.
Visitors who prefer to make their browser window wide (perhaps because they're able to read long lines easily, or because they prefer to avoid vertical scrolling as much as possible) are screwed as well, because the fixed pixel width wastes space and prevents them from reading as they'd prefer.
Visitors who make their browser window narrow (perhaps because they're doing several things at once and want to save screen space, or so they can look at two or more pages side-by-side, or because they have a small screen and can't resize the window any larger) are doubly screwed in this scenario, because they now have to scroll horizontally for every line - not conducive to easy reading, I'm sure you'll agree.
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.
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:
See the horizontal scrollbar? Toss your cookies.
Jeanne A. E. DeVoto jaed@jaedworks.com