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:
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
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
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:
I prefer this style to that chosen by many other designers who use a centered
The HTML 4 specification adds a new
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
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
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 (
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
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
This page was first created 31 Jul 1997, and was last modified 01 May 2013.