---

Stuart Moulthrop & Nancy Kaplan
University of Baltimore
School of Information Arts and Technologies · Revised 2008

---

Part 4: Tables

When the Web first got started, most pages looked as if they could have been typewritten on a fairly crude machine. Text was basically flush-left with a ragged right margin, formatted mainly with indentation and skipped lines. The right margin tended to be unconstrained, so line widths stretched out at the whim of the viewer, often to absurd extents.

As the Web grew out of infancy, however, its pages came to resemble popular mazines (and vice versa), featuring multiple columns, sophisticated page grids, and a complex balancing of text and image against negative space. Eventually, Web designers also brought in dynamic elements such as graphics and grid components that could be updated without reloading the entire page.

Two crucial innovations underlay these important developments in Web design. One was content management through server-side integration, a technology that began with Common Gateway Interface scripting, and quickly grew into an array of sophisticated approaches. The other was the table, an HTML construct (actually, a suite of page elements) introduced with Netscape Navigator 1.1 (1995), and incorporated into HTML 3.2 and subsequent standards.

Sophisticated content management lies beyond the scope of this introductory course, though you'll make a first acquaintance of JavaScript in Part 8. Tables, on the other hand, remain essential to basic Web design, though their function in page architecture and layout has largely been replaced by Cascading Stylesheets.

Strictly speaking, the Internet was not meant to support anything like the World Wide Web, and the Web in its early days was hardly envisioned as a system for general-purpose communication. Like the Internet, HTML and HTTP were built for scientific exchange.

So it shouldn't be surprising to learn that the table -- a mechanism for displaying information in a two-dimensional grid -- was meant primarily to handle numbers. Tim Berners-Lee and the other wizards of CERN did not envision portals, home pages, and blogs (though the very first thing called a Weblog was in fact Berners-Lee's home page). They were thinking about technical reports. This is the story of the Internet, however: once you let The Rest of Us through the door, it's not the same party. Some people want to wear the lampshades.

The clever folks at Netscape made some interesting adjustments to the original table specifications when they implemented this feature in their Navigator 1.1 browser. For one thing, they set to zero the default value of the table's BORDER attribute, which controls the appearance of lines that mark rows and cells. This means that the framework of any table is invisible by default. You see your content, nicely constrained by a regular grid, but the grid does not jump out at you the way it might in a logarithm table. In other words, Netscape's vision of tables had more to do with page layout and screen design than with spreadsheets and quantification.

Theoretically, this layout function of HTML tables belongs to the past. The Cascading Stylesheet standard (CSS) provides a much richer and more powerful set of tools to control the structure and appearance of pages. However, even many years after the introduction of CSS, browser support for this technology is still annoyingly far from universal, thanks largely to the stubborness of certain large commercial interests that shall remain nameless. This means designers must still resort to tables for certain purposes, if they intend to accommodate a very large range of browsers.

It's worth remembering, though, that the use of tables for layout is inherently perverse. There's a reason why the innermost container of HTML tables is called TD (table data) instead of something like, say, TC for table cell. Tables are meant for data, mainly numerical values, and they are still enormously useful for that purpose. Just bring those invisible borders back into view.

4.2.1 Table Markup

The following example shows the markup for a minimal table: a single row with a single cell.

Markup	Output
<TABLE BORDER="1"> <TR> <TD> WATCH THIS SPACE </TD> </TR> </TABLE>	WATCH THIS SPACE

Most tables in use on Web pages are built out of three fairly simple components--the following containers:

<TABLE></TABLE>

This is the general container for the table construction as a whole.





<TR></TR> (Table Row)

This container holds the information for a single horizontal array of table cells (a row).





<TD></TD> (Table Data)

This container holds the contents of a single table cell, which may be words, images, or any other element of HTML markup including another table!

As indicated above, every table must include at least one instance of each of these containers.

You'll sometimes also see a fourth container, <TH></TH>, designed to mark the heading for a column of figures. Text within a TH container occurs in bold and is horizontally centered by default. Hence this container is not especially useful for layout, though it is a good example of structural markup: a container that provides useful information about the function of the text within it.

It's worth noting here that although tables are two-dimensional grids with both vertical structures (columns) and horizontal structures (rows), only rows are defined by a container. Columns are in effect just stacks of individual cells. There's no container to delineate columns.

4.2.2 · Attributes of the <TABLE> Tag

HEIGHT, WIDTH

These attributes set the vertical and horizontal dimensions of the table as a whole; they may be set in pixels (e.g., WIDTH="600") or as a percent of the visible window (e.g., HEIGHT="50%"). Note that if you use percentages, your table will be automatically resized if the window size changes, retaining proportional relationships among its contents. This enables a number of interesting and useful effects, such as vertical centering, described below. But a table sized by percentage does not fix a limit for the right page margin, so it does not solve the "wall of text" problem, also described below.





CELLPADDING, CELLSPACING



Cellpadding sets the amount of space between border lines and contents of table cells; cellspacing sets the amount of space between cells themselves; both are set in pixels. Though cellspacing and cellpadding are subtly different, the difference is invisible unless the border lines of your table are visible (see next item).





BORDER

This attribute controls the dimensions of the lines that separate cells in the table. The default is zero (no visible lines). The example above has visible lines because its initial TABLE tag contains the attribute BORDER="2". If visible, border lines are shaded (given a faux 3-D look) by default. There is no NOSHADE option for this feature.





ALIGN

Left, right, top, bottom, and center are available values for this attribute, but practically speaking only the first two (lateral) values are much used. Alignment in tables works as for images: page content flows around a left or right-aligned table. With some constraints, this lets you create very sophisticated embedded and irregular layout structures: grids within grids. It's especially useful for layout effects like call-outs, dropped caps, and captions which require adjacency (see below).

4.2.3 · Attributes of <TR> AND <TD>

ALIGN, VALIGN

These attributes set alignment for a single cell or an entire row. Possible values are top, bottom, left, right, center. By default the content of any table cell is laterally aligned on the left and vertically aligned in the center. Add ALIGN and VALIGN attributes only if you wish to override those settings. Effects of these attributes are local, so it is possible to have a left-aligned cell within a right-aligned row.





Default values: horizontal left, vertical center.

Alignment set to "right" and "top."





HEIGHT, WIDTH

These attributes set dimensions for the cell or row and may be set either as pixels or percentage. As with the TABLE container, percentage settings allow the elements to scale proportionally if window size changes. You may use percentage settings for <TR> and <TD> even if you have set the overall dimensions using absolute pixels in the initial <TABLE> tag.




Note, however, that the size of table elements can be problematic. You don't always get what you ask for, especially if you rely on relative measures like percentages. But there are ways to fix dimensions for table elements, as discussed below.

4.2.4 · BGCOLOR in <TD>

In the third generation of browsers, both major players (Microsoft and Netscape, in those days) agreed to support the BGCOLOR attribute for table cells, using the same conventions for color reference that apply to BGCOLOR in the BODY tag. Here's what this enhancement makes possible:

She	COMES
in	colors
everywhere

This technique gives you a way to set a local background color for a region of your page. Used more rationally than in the example above, BGCOLOR in table cells lets you mark off certain cells or rows, for instance if they are headings or major structural elements of the design.

Note that there is no color control for the border lines between cells. However, you can achieve much the same effect with a little inventiveness:

Clever trick... Must involve a table within a table!

4.2.5 · BACKGROUND in <TD>

All contemporary browsers support the use of BACKGROUND in the TD tag. This attribute functions here exactly as it does in the BODY tag: the indicated image is tiled to fill the space of the table cell, with content laid over it.

It's In Here Somewhere!

Do you know where your files are?

4.2.6 · COLSPAN and ROWSPAN

These two crucial attributes allow you to produce tables using irregular grid structures. COLSPAN allows a table cell to occupy the horizontal space allotted to more than one cell. ROWSPAN does the same for vertical space.

The effects of these attributes are better illustrated than described. Let's begin with a regular grid structure:

Markup	Output
<TABLE BORDER="1">  <TR>    <TD>Northwest</TD>    <TD>Northeast</TD>  </TR>  <TR>    <TD>Southwest</TD>    <TD>Southeast</TD>  </TR> </TABLE>	Northwest Northeast Southwest Southeast

The table produced by this markup (above right) is entirely symmetrical, having two rows and four cells, two in each of the rows. The cells all have identical dimensions. This sort of arrangement works very nicely for tables of numbers, but complex Web content often demands a more sophisticated approach. Consider the following:

Markup	Output
<TABLE BORDER="1">  <TR>    <TD>Northwest</TD>    <TD>Northeast</TD>    <TD ROWSPAN="3"      VALIGN="MIDDLE"> OFF<BR> SHORE</TD>  </TR>  <TR>    <TD>Southwest</TD>    <TD>Southeast</TD>  </TR>  <TR>    <TD COLSPAN="2" ALIGN="MIDDLE">       DEEP SOUTH</TD>  </TR> </TABLE>	Northwest Northeast OFF SHORE Southwest Southeast DEEP SOUTH

In the example above, the cell containing the words "OFF SHORE" is given a ROWSPAN of 3, so that it occupies vertical space that would normally be taken up by 3 cells. The cell containing the words "DEEP SOUTH" has a COLSPAN of 2, allowing it to take up the horizontal space of 2 cells.

Though enormously useful, COLSPAN and ROWSPAN can make table markup rather confusing. Cells handled in this way steal space from other rows and columns, which means that those subsequent structures will have fewer cells in them than they would have had in a regular grid. It's easy to lose track of the overall design of your table when trying to read the markup for irregular grids. We strongly recommend that you diagram your layout structure.

Finally, a note on semantics. Columns (stacks of table cells) are vertical structures, delineated by lines that run from top to bottom of the screen; likewise, rows are horizontal structures delineated by lines running from left to right. So why does COLSPAN affect the horizontal allocation of table space and ROWSPAN vertical space?

You can complain all you like that someone got the terms confused; there is no way to change this part of the language now. If it helps, think of COLSPAN as setting the width of a column and ROWSPAN as setting the height of a row. In any case, do not confuse COLSPAN, which works across the table, with ROWSPAN, which works down the table.

4.2.7 Tables Within Tables

Have a look at the two tables below, paying particular attention to the alignment of cell borders from one row to another:

Cell 1.1 Cell 1.2 Cell 1.3 Cell 1.4 Cell 1.5

2A1 2A2 2A3 2B1 2B2 2B3

Table 1 consists of two rows and five cells with cell 1.4 set to span two columns, while Table 2 actually contains tables 2A and 2B within it.

Why would anyone want to do something like this? Well, embedding a table within a table lets you create very sophisticated layout structures, freeing you from the constraints of a single, regular grid. Note that in Table 1, the right boundary of cell 1.4 is fixed by the structure above it: the width of 1.4 is doubled over the width defined by cells 1.1 and 1.2. Likewise, the width of cell 1.5 is determined by the width of cell 1.3. Now compare Table 2, where the subtables A and B have totally independent boundaries.

Multiple-table layouts were once quite common in Web design. Typically, the outermost table in an embedded-table layout defines the general boundaries of the page (see below), while the interior tables define relationships of elements in subordinate sections or departments.

Embedded tables are nearly the most infernally complicated things known to the Web. You may decide to have nothing to do with them: though you may also find that the equivalent CSS strategies have their head-pounding aspects, too.

To help sort out the complexities of embedded tables, for those who still care, we've extracted the relevant part of the markup and put it on a special text page which you can print out for closer study.

Practically speaking, however, you'll probably never need to use tables for anything this beastly.

4.2.8 · Fixing Dimensions of Table Cells

As you begin to work with tables, you may have a few frustrating experiences involving text. Let's say you create a table with WIDTH set in the initial TABLE tag to 600 pixels. You set up two cells in the table's single row, each with width set to 50%. Within each cell you place some ordinary paragraph prose.

Though everything might turn out fine (assuming you're lucky), if you keep building tables like this, sooner or later you'll see one in which the 50/50 width division doesn't work out. Let's suppose you then set the TD width in absolute pixels, 300 for each cell. Nice try, but it won't help.

What's going on? Well, words wrap. Depending on how your browser's layout engine decides to break the lines of your text (which in turn depends on the font being used for display), the cell you intended to be 300 pixels can shrink to something much less. In fact, your whole table could fail to measure up to the 600 pixels you specified.

There's a fairly simple solution for this problem: use a single-pixel graphic (remember those from the previous part of these notes?) set to the precise width or height you want. Slip this graphic in after your paragraph text. If it's the same color as your page background (or the particular cell background), no one will know it's there. And since unlike text, graphics don't break or wrap, you'll be guaranteed the dimensions you want.

This vast table cell is three hundred pixels wide!

Hardly; but this one is.

The solution above deals with collapsed or undersized tables; but you may see the opposite problem as well: tables designed for a particular width or height which seem somehow to expand beyond their specified limits. In this case, inserting a fixer graphic won't help: table cells always expand to accommodate their contents, and even if you place a measured graphic in a first-row cell, oversized content occurring in a later row will cause the whole table to be reconfigured.

In most cases there's a graphic to blame. If you suffer a table blowout, check the dimensions of every graphic on your page. If any exceeds the size you've set for its cell, either change its native dimensions by editing its image file, or alter the WIDTH and HEIGHT values in its IMG tag. On rare occasions, blowouts may also be caused by very long lines of non-breaking text. You may need to insert BR tags to bring things under control.

4.3.1 · Constraining the Right Margin

Take a close look at the reduced image of a Web page that appears below. To get the full effect, click on the graphic to view the actual page. Expand the width of the window in which the page appears. Notice what happens.

Scientists who study the physiology of reading have known for decades that you should never put too many characters in a single line of type. Excessively long lines actually lead to eyestrain by forcing readers to deflect their eye muscles more than is comfortable. Long lines also make comprehension more difficult: it's hard to take in information in a quick glance when you can't see the entire line at once. Yet in the original HTML specification, there was no way to fix the length of a line. If their monitors were big enough, readers could extend pages to truly ridiculous widths. This problem came to be known colloquially as Wall o' Text.

TO THIS DAY, for reasons we fail to comprehend, many people who build Web pages pay no attention to this problem. Some contend that every user should be able to set window size as he or she likes. This position assumes, of course, that readers have time to tinker with window widths as they browse from page to page. We suspect people who think like this don't spend much time with actual Web users.

As a general rule, any page that features more than a sentence or so of text needs a fixed right margin. There is a perfectly good and easy way to do this using Cascading Stylesheets, and it works in nearly every Web browser you will encounter. Unfortunately, however, nothing in the Web world is truly universal, so you may still need to fix your right margin using a table, especially if you need to accommodate users of older or unconventional software (e.g., on phones or game consoles).

Here's how to manage the problem in the Olde Way. Set up a minimal table with one row container <TR></TR> and one cell container <TD></TD>. Assign an appropriate WIDTH attribute. Place all your page information within the TD container. Voila, no more Wall o' Text.

But what value should you use for page width? These days, the preponderance of personal computers support full-color display at resolutions exceeding 1000 pixels in the horizontal dimension, and 700 pixels in the vertical. Laptop displays, which are typically much wider than they are tall, sometimes afford even more laterial space. Therefore, a maximum governed width of 650-750 pixels entirely safe if you are producing Web content for laptops or PCs. The number of characters you can fit into this space depends on font size; and of course, if you're building for handheld devices or appliances, you're in another world entirely.

At the end of the day, though, we're willing to bet that 650-750 pixels will endure as a sensible page width until somebody comes up either with superior display technology, or a replacement for the human eye. That display width yields a line on which the most popular fonts are most readable, especially to people with less than perfect eyesight -- and sooner or later, that's everyone.

4.3.2 · Vertical Centering

Suppose you want to center content both horizontally and vertically on an HTML page. The horizontal problem is easily solved by placing your content within a center-aligned paragraph tag or DIV, but what about the vertical dimension?

The best solution probably lies in a DIV or other CSS-related element, but you may find you need absolute positioning to pull off this trick -- a CSS feature that's not universally supported by browsers.

Next-best solution: create a table whose HEIGHT and WIDTH are both set to 100%, then set up a TD container with ALIGN set to "center." Place your content within that cell. Contents of table cells are vertically aligned (VALIGN) to center by default, and the horizontal ALIGN setting guarantees correct lateral position.

4.3.3 · Table Alignment Effects

Cover from eSenior, PBDS Final Seminar, 2000.

In Part 3, we described a solution for setting page features like graphics so that text flows around them, based on a DIV and embedded stylesheet. Again, this is probably the better way to handle this layout effect, but you can achieve the same end using a table.

With the introduction of Navigator 2.0, Netscape added an ALIGN attribute for the initial TABLE tag; this attribute does exactly the same thing for tables that it does for in-line graphics when it's used in the IMG tag: it sets the table to the right or left of everything else in the layout. The adjacent content flows around the table.

This effect can be used for a number of important design techniques, such as call-outs, brief excerpts in an enlarged typeface that draw the reader's eye to a particular block of text; or enlarged, ornamental capital letters ("dropped caps") at the beginnings of sections or paragraphs; or as in the illustration here, simply for captioning. Unless you incorporate the lettering of the caption into the native graphic file, the only non-stylesheet way to coordinate caption text and image is through use of an aligned table.

VSPACE and HSPACE work for aligned tables just as they do for aligned graphics. The problem of symmetrical gutters occurs here, too (remember Part 2), but tables afford a better solution than embedding a gutter strip in the image. As you can see in the schematic below, the left-aligned table that holds the graphic and caption

IMAGE CAPTION

includes a righthand cell with a ROWSPAN of 2. This cell holds a spacer graphic color-coordinated with the page background and set to 10 pixels in width. There is no HSPACE attribute in this table: the gutter is created solely by the righthand cell. If necessary you could add a third row, containing a cell with a colspan of 2 that would hold another spacer graphic with width of 1 and height of 10. This would create a lower gutter.

Index · Part 1 · Part 2 · Part 3 · Part 5 · Part 6 · Part 7 · Part 8 · Part 9 · Top

---

Course and Materials ©1997 - 2008 by Stuart Moulthrop and Nancy Kaplan