Dan's Web Tips:

Tables

Tables were first introduced to HTML in the never-adopted HTML 3.0 proposal. Despite their not being an official standard yet, Netscape implemented them, and eventually the HTML 3.2 specs endorsed the use of tables (which were by then already supported by most browsers). Tables were originally intended for use in presenting data arranged by rows and columns, like timetables:

Hudson Line
Grand Central	11:54	12:54
125th Street	12:04	1:04
Croton-Harmon	12:53	1:53
Poughkeepsie	1:43	2:39

However, the graphical-design crowd quickly seized upon the use of tables to produce layout effects. This was yet another move towards visual rather than logical design of Web pages that had purists tearing out their hair, but it was here to stay -- while, in principle, one could use stylesheets to achieve all the effects of table layout and more, and "Web purists" advocated doing so strictly, for a long time there were serious problems; some old browsers, like Netscape 4, had highly buggy stylesheet implementations that were OK for simple stuff like fonts and colors, but were likely to make a mess of fancy layouts; this meant that for many years stylesheets were considered "not ready for prime time". Also, tables do tend to be somewhat easier (though not trivial) for novices to learn, if they already know some rudiments of HTML, because stylesheets are in a whole new language and require learning an entirely new set of principles that tend to be alien to people who think "You just plunk in a tag, and it makes the browser do stuff!". Over time, I'm making increased use of stylesheets and decreased use of old-fashioned "hacks" like layout tables and font tags, but I'm somewhat conservative and pragmatic about it. One of these days, I'll redesign my site to stop using layout tables!

If done carefully, the use of tables for layout can produce nice effects without greatly harming the appearance of the site in environments differing from that of the designer. If done carelessly, though, they can produce a site that is a total mess on a different browser or with different settings in a browser. Here are some hints on making your site the former instead of the latter.

Dealing with Different Screen Widths

TIP: Don't hard-code pixel widths in your tables!

A big plague on the net these days is the hardcoded pixel width, such as <TABLE WIDTH=600>. This is a bad idea. A user with a browser window width less than 600 will get an annoying horizontal scroll bar. (Except for WebTV users, that is; WebTV doesn't use horizontal scroll bars, and instead does whatever it can to cram all Web pages into its width, such as shrinking graphics and re-word-wrapping text, ignoring any author attempt to prevent this.) With a width greater than 600, there will be extra whitespace, and the layout may be way off center. Only on a screen that's "just right", with the browser window sized properly, will the layout actually look the way the designer intended it.

Such hardcoding should never be necessary. HTML constructs, if used in a properly logical way, have a great ability to resize themselves to suit the user's system. A normal block of text will be made wider or narrower as the user resizes his browser window, with word-wrap points changing accordingly. Try resizing your browser now, and see how wide a range of sizes this page will accommodate. That's the way HTML was always designed to work, and it never ceases to amaze me how great lengths some designers go to defeat this sensible behavior.

Some will say, "But long lines are hard for the user to read!" However, a user who is bothered by long lines is always free to resize his browser window to the line width he or she finds pleasing to read. This may be a different width than the author thought was optimal. Different users have different preferences; some are more bothered by long lines, while others are more bothered by having to do lots of scrolling, and would prefer to fit more text per screenful using longer lines.

Some fixed-pixel-width pages wind up at the opposite extreme from overly-long lines, anyway. When the author designs the page to fit a (so-called) "lowest-common-denominator" 640x480 window, and takes up much of this width with menu buttons, graphical gimmicks, and advertisements, the screen width left for actual text content is a minuscule column which doesn't get any wider even for users with wide monitors. These pages are sometimes referred to as "bacon-strip pages," since their text is about as narrow as a strip of bacon. If the article is long, you're likely to scroll past all the graphics and still be reading the text in a silly-looking strip surrounded by lots of whitespace.

Many designers who use the "long lines are hard to read" justification for fixed pixel widths are also the same ones who use FONT SIZE tags to force fonts smaller than normal for body text. This reduces the readability. Let the fonts stay at normal size (which, by definition, is supposed to be the size the user has configured as most readable), and they'll be easier to read even at longer line lengths. Anyway, you have no way of knowing exactly how many characters per line your pixel width corresponds to, since font sizes will vary by browser and platform (and can be reconfigured by the user). And if you try to force the line breaks with hardcoded <BR> tags, this could produce odd line breaks if the user has a larger font than you expect, causing a browser-induced line break a word or two before your forced one. So you wind up with a normal-length line followed by a one-word line, followed by another normal line, and so on. This looks really stupid.

TIP: You can use percentages as widths in order to influence the layout in a manner compatible with variable screen sizes.

You can achieve layout effects in a more screen-friendly way by using percentages instead of absolute values. With HTML 3.2, the standards only let you do this for the table as a whole, not the individual cells, though nonstandard attributes supported by the popular browsers let you add percentages on table cells too. However, the newer HTML 4.01 standard, to which my pages validate, does allow percentage widths on cells as well.

Unfortunately, there is a browser incompatibility in the implementation of this attribute; Microsoft Internet Explorer interprets such percentages as the percentage of the entire browser window, while Netscape interprets them as the percentage of the table. This is the reason the standards body originally didn't allow this attribute, and a good reason not to use such percentages in most cases, but the one "safe" time to do it is in a table of width 100%, where the two interpretations of cell percentages agree.

For instance, if you want to set aside left and right margins on your page, you can do it with:

<TABLE WIDTH="100%"> <TR><TD WIDTH="10%"></TD><TD> ... put your page body here ... </TD><TD WIDTH="10%"></TD></TR> </TABLE>

I prefer this style to that chosen by many other designers who use a centered <TABLE WIDTH="80%">; this latter approach causes browsers that support the CENTER tag but not the TABLE tag to center all the text, probably not what the designer wanted. However, there are other, better ways of providing margins without using any extra blank table cells -- one way is to use the cellpadding attribute to add a margin to the table (though this adds it to the top and bottom as well), but better yet is to use a stylesheet, where you can set top, bottom, left, and right margins for the page as a whole or any element of it in a number of different units including pixels, percentages, and "ems" (a unit that scales itself to the user's font settings), and even Netscape 4 can handle this most of the time.

The HTML 4 specification adds a new <COL> tag which takes widths either as a percentage or a pixel value, but I'm not sure if it's widely supported, and its use for layout control is better done by stylesheets anyway.

Be sure to put quotes around percentage attributes, since the HTML specifications call for the use of quotes on all attribute values that contain characters other than letters, numbers, and periods.

If you really do need a hardcoded size somewhere, like to make the left margin of your text indent far enough to get around a background graphic, put in a WIDTH attribute for that particular column, but don't hardcode sizes for the remaining columns of the table or for the table as a whole; you've got no reason to prevent those from resizing. (Since even table columns with hardcoded widths are often resized against the designer's will, you can force the width using a blank spacer graphic; just be sure to put ALT="" in the IMG tag so that text-browser users don't get an ugly [INLINE] at that point.) Incidentally, if you're using a background graphic with an element you want at the left edge of your page, be sure the space to the right of it is wide enough so that the graphic won't repeat even in the widest screen setting. Make it at least 2000 pixels wide. Unlike with hardcoded table widths, browsers are smart enough to cut off the right part of a background graphic that's too big to fit on the screen.

One thing to note about putting an entire page in a table as above is that on some browsers it will cause none of the page to be displayed until all of it loads; so it's not a good idea to do this on really large pages with lots of text. (The size of the graphics shouldn't matter as long as you use WIDTH and HEIGHT attributes.) You might break up a really large page into several different tables so part of it can display before the rest loads. Once somebody accessing this site from overseas reported frustratingly long delays, plus a page that forced a left-right scroll because one of the lines was too long (and the whole page, being in a table, resized to suit it). This convinced me at the time to drop this use of tables for overall page layout, but they've crept back in with my latest redesign (a bit of "Do as I say, not as I do" on my part...). Please let me know if you experience any difficulties as a result. I might just do another redesign and this time do everything with stylesheets in a thoroughly purist manner.

Making Tables Degrade Well on Non-Table Browsers

This was a bigger concern a few years ago when lots of people were still using browsers that didn't support tables, and sites done with tables often became a total mess on such browsers. Nowadays, the non-table population is much lower, confined mostly to users of an outdated version of the AOL software. Even the latest version of text-mode browser Lynx makes an effort to keep tables from becoming a mess by putting in whitespace between the elements. However, if you'd like to be sure your site is more widely viewable even by the few still using old browsers, there are a few things you can do.

The main thing is to be sure there is some space, either horizontal or vertical, between table elements so they don't run together if table commands are ignored. You can force vertical space by putting a paragraph tag (<P>) at the start of a table element, or a line break tag (<BR>) at the end of a table element. (Don't do it the other way, with the paragraph break at the end or line break at the beginning, since some popular browsers will then put extra vertical space in the table element, probably ruining the layout.) Or if a little horizontal space is all that's needed, just be sure there's at least one space either at the beginning or the end of the table cell, or in between the </TD> at the end of one cell and the <TD> at the start of the next one.

But if the two adjacent cells contain graphics you'd like to be sure are touching, put the space only between the cells, not within either of them. (And be sure to specify BORDER=0 in the TABLE tag; though this is the default, if it's not explicitly stated some browsers will put a little bit of space between columns.) And don't put an extra space within a link (<A HREF=...> ... </A>), or you may get an underlined space at that point.

Always Close What You Open!

Although not all the ending tags for table elements are actually required by the specs, get in the habit of closing all table elements, since some browsers get confused if you don't. That means that every <TR> has a corresponding </TR>, every <TD> has a corresponding </TD>, and the table ends with a </TABLE>. All the TDs must be nested within a TR, and all the TRs must be within a table. Don't put any content outside a TD (table data cell). If you do something like </TD> some text <TD>, it is undefined where "some text" will wind up; a browser might put it anywhere on the screen, or skip it altogether. If you nest tables within other tables, be sure all the tables and their elements are properly closed.

Links

[<== Previous] | [Up] | [Next ==>]