Tables

HTML 3.2: Here's Wilbur!, created in 1997 by Eric Meyer, is maintained on this server for historical reference. While much of this information is still relevant, it is important to remember that it was written for HTML 3.2. The more current versions of HTML and XHTML in use today have different requirements. To learn more, you may also wish to review our Web Development blog entries on HTML/XHTML and Cascading Style Sheets.

All right, it's time to learn about tables! This subject will take two chapters to get through. The first of the two chapters-- that's this one-- will explain how tables are constructed and introduce all of the tags related to tables. The second chapter will discuss in gory detail the various attributes you can add to the tags, and how they can be used to create some very interesting effects.

TABLE

To start with, tables are containers, so a truly minimal (if useless) table would have the following markup:

   <TABLE>
   </TABLE>

Okay, okay, it's boring, but it made the point, right? Right. All other table elements will go between those two tags. That's simple enough, isn't it?

Before we go any farther, I'm going to mention an attribute of the TABLE tag which gets a lot of use. Ordinarily, a table will be rendered without any borders, so that the data is arranged in discrete cells, but the cells themselves can't be seen. This can be useful, but most of the time, it helps to be able to see the actual structure of the table. To do this, just add the word border to the TABLE tag, so that the opening tag looks like this:

   <TABLE border>

This isn't the only attribute to TABLE, but the rest will wait until the next chapter. I only bring border up now because I'm going to be using it a lot in this chapter, and I thought you should know ahead of time what was going on.

Okay, back to the theoretical discussion. Each table is divided into rows, and each row is divided into a number of cells. Therefore, when you're planning a table, think of it as having this basic structure:

The next chapter will introduce more specifics (and a few wrinkles) concerning this model, but for now, let's stick with the way of thinking shown in Figure 1. The height of each row, incidentally, is determined by the height of the tallest cell in that row. The browser itself will automatically figure out how tall that is, based on the data it has to display and the way that data has been arranged.

Each row is specified using the "table row" container, comprised of the tags <TR> and </TR>. Therefore, a blank three-row table would be written as:

   <TABLE>
   <TR></TR>
   <TR></TR>
   <TR></TR>
   </TABLE>

This still isn't enough for a useful table, however. Each row needs to be divided into a number of cells.

Note that there is no way to explicitly specify how many cells are in a given row-- that number is implicit in the cells themselves. In other words, if a row container has four cell containers in it, then that row obviously has four cells. And how, you are no doubt asking, does one specify a cell container?

There are two ways, actually, because there are two types of cells: data cells and heading cells. We'll look at data cells first, since they tend to be much more common.

Data Cells

A data cell is specified using the container <TD>...</TD>, and there can be any number of these cells in a given row. The contents of a data cell are generally referred to as "table data," which is where the letters TD come from. Any kind of information-- text, images, and so on-- is considered data for the purposes of tables. Therefore, most of your cells will contain data of one kind or another:

   <TABLE border>
   <TR>
   <TD>one kind</TD>
   <TD>another</TD>
   </TR>
   </TABLE>

As you may have guessed, the markup for a table can get to be very large very quickly. If you have a table that is four rows of seven cells each, and your markup looks similar to that shown above (each row tag is alone on a line, and each cell gets a line of its own), then markup for this hypothetical 28-cell table would be 38 lines long! Things get even worse if you have a lot of information in each cell, and if you start throwing in blank lines to make examining the markup easier.

My recommendation is that if you're using a word processor or editor which does automatic indenting, you should use it to the fullest. For example:

   <TABLE border>
      <TR>
         <TD>Row 1, Cell 1</TD>
         <TD>Row 1, Cell 2</TD>
      </TR>
      <TR>
         <TD>Row 2, Cell 1</TD>
         <TD>Row 2, Cell 2</TD>
      </TR>
   </TABLE>

That way, it's easier to get a feel for the table's structure without having to leave yourself a ton of comments.

Data cells can be arbitrarily large, and as I indicated before, a cell can contain nearly anything: text, both regular and monospaced; lists, both ordered and unordered; images of any size; horiztonal rules; forms; and even entire tables! Here's just one possibility:

This is the first cell.	Cells can contain: text images tables and more!	Images, too:	This is the fourth cell.
	More text, in this, the sixth cell.	And last.

For brevity's sake, I have copied the above table to an example page, where you can view it and the markup which went into creating it. Check out the details!

You'll note that in each of these examples, I've made sure that each row has an equal number of cells. This is not required. What happens when rows have an unequal number of cells? Here's one example:

The overall table is always rectangular in shape, so "leftover" space is simply left blank. Nothing will warn you that the table has a ragged edge, so to speak, except checking it yourself. Rows of unequal length are perfectly legal, and sometimes even useful.

You can force blank space to show up at the beginning of, or in the middle of, a row by inserting an empty cell. This is done using the tag sequence <TD></TD>. Let's say that we want the above table to have its rows be "right-justified," in the sense that the blank space is all on the left side of the table, like so:

In this case, the markup for the third row is:

   <TR>
      <TD></TD>
      <TD></TD>
      <TD></TD>
      <TD>Row 3, Cell 1</TD>
      <TD>Row 3, Cell 2</TD>
   </TR>

The "blank" cells take up space in the table's structure, but don't show up in the browser window. This can be pretty handy when you need to set up a complicated table and need separators.

Heading Cells

Sometimes, you will want certain cells to stand out, because they contain labels or column titles or something similarly important. For these situations, there is a special type of cell called a "heading." This cell type has different display rules than regular data cells, so that it stands out in the crowd (so to speak). To give you an example, I've set up a table which lists a number of foods and their popularity among a sample audience:

(Please note that I made those numbers up.)

Now, the text in the first row should look different than the rest of the text-- bigger, maybe boldfaced, perhaps in a different color, but still different. That's because those cells are table headings. This type of cell is specified using the tags <TH>...</TH> (the letters "TH" come from the term "table heading").

How the browser displays table headings will vary; for example, Netscape will boldface and center the text within the cell, whereas Mosaic will let the user define the display strategy. Table headings may be defined anywhere, even in the middle of a row and surrounded by data cells. That's because headings are intended as a structural notation. You can put them anywhere that would make sense, instead of being constrained to the first row or cell, or something like that.

For further examples, you could look through my Table Examples page, which contains some original constructions as well as some specimens I swiped from the Netscape site.

According to the HTML specification, the close tags </TR>, </TD>, and </TH> are all optional, in much the same manner as the </LI> tag is not required. This makes markup quite a bit easier, since you don't have to keep typing all those close tags. In the real world, however, browsers such as Netscape have a much higher chance of getting confused or crashing if you omit these end tags. The one which seems to cause the most trouble is </TR>, so I recommend that you explicitly close all of your table rows, and only close heading and data cells if you really feel like doing so.

CAPTION

Tables can also have a caption associated with them. The text enclosed in the CAPTION tag will be placed at either the top or bottom of the table, depending on what value is given to the align attribute. Let's take the food-survey table from the last section and give it a caption.

   <TABLE border>
   <CAPTION align="bottom">Fig.3: Survey Results</CAPTION>
   [...rest deleted for brevity...]
   </TABLE>

Note that the CAPTION container can be placed anywhere in the table, as long as it isn't inside a <TR> container. You should also have a maximum of one caption.

A Mild Warning

When putting together a table, something you need to think about is how the table will degenerate in a browser which doesn't understand tables. Let's say you're trying to look at a page with tables using an older Web browser such as Mosaic 1.0.3, which doesn't understand tables at all. In that case, the table tags will be ignored, as any good Web browser will simply ignore tags it doesn't understand. Therefore, the above food-survey table will look like this:

Fig.3: Survey Results Food Like Hate Don't care Pizza 93% 4% 3% Brussels Sprouts 44% 47% 9% Pork Chops 68% 15% 17% Mashed Potatoes 71% 24% 6% Ice Cream 98% 1% 1%

That's bad enough, of course. It gets worse when you've arranged the data in the table in such a way that it will get hopelessly scrambled in a table-ignorant browser. This is what we call "graceless degradation." The goal, as you might suspect, is "graceful degradation," in which the data is at least displayed in the right order, if not necessarily very attractively-- although that's always nice to achieve as well.

Figuring out how a table will come apart is very simple: the data will be displayed in whatever order it appears in your HTML file. This isn't much of a problem right now, but just wait! Once I get into some of the cell attributes in the next chapter, you'll see that things can become very complicated very quickly. Of course, at that point, I'll explicitly discuss this issue anyway, since I can't very well pass up an opportunity to belabor the obvious.

Speaking of Which...

What we have discussed so far by no means defines the limit of what can be done with tables. In the next chapter, we'll review a number of attributes which will let you create much more interesting and useful tables than the ones we've seen so far.

Chapter 6 Quiz
Next-- Chapter 7: Tables II
Previous -- Chapter 5: Structural Effects
Table of Contents
Tutorial Glossary
Tutorial Index
The HTML Laboratory
Tutorial Feedback