Week 4: Tables, Frames, and Layout

When the Web first got started, most pages looked as if they could have been typewritten: text was basically flush-left with a ragged right margin, formatted mainly by indentation and skipped lines.

Now, however, many Web pages resemble what you see in Wired or iD (and vice versa, of course); and a similar exchange goes on among TV, video games, and the Web. Web designers now regularly use multiple columns, sophisticated page grids, and a complex balancing of text and image against blank or negative space. They've also brought in dynamic elements such as graphics and grid elements that can be updated without reloading the entire page.

These important developments in Web design depend largely on two crucial innovations in HTML: tables, popularized by Netscape with Navigator 1.1 in 1995, and frames, introduced with version 2.0 the following year.

As you'll see, frames have stirred up a certain amount of controversy and are not as widely used as they once were. Tables, on the other hand, are nearly ubiquitous. Both concepts are essential to contemporary Web design.

4.1 | TABLES

4.1.1· You're Not Supposed to Do THAT!

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 have in mind portals, home pages, and Web zines; they were thinking about technical reports. But that's the story of the Internet: 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 young 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 spreadsheets and quantification.

Since 1995, tables have been the power tool of Web design. It's worth remembering, though, that the way we use tables amounts to a huge technological perversion. There's a reason why the innermost content container of HTML tables is called TD ("table data") instead of something like, say, TC for "table cell." Generally speaking, tables suggest a regular and uniform structure. Designers spend much of their time figuring out how to escape that regularity and uniformity by outsmarting the basic rules. Tables are an excellent case in point.

4.1.2· 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>

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





<TR> (Table Row)

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





<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.

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

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).

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: left and 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.

Somewhere around the third generation of browsers, both Microsoft and Netscape 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 effectively 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!

All Microsoft browsers after 3.0 and Netscape browsers after 4.0 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?

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.

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 are quite common in Web design. Typically the outermost table in am embedded-table layout defines the general boundaries of the page (see below), while the interior tables define the relationships of elements in subordinate sections or departments.

Embedded tables are nearly the most infernally complicated things known to the Web. To help sort out the complexities we've extracted the embedded-table part of the markup and put it on a special text page which you can print out for closer study.

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, you see. 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 last week?) 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.

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 also 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 as Wall o' Text.

Fortunately, tables saved the day. As a general rule, any page that features more than a sentence or so of text needs a fixed right margin. Set up a minimal table with one row container <TR></TR> and one cell container <TD></TD>. Assign an appropriate WIDTH attribute. (For current common screen resolutions, which range around 800 pixels in width and600 pixels in height, a good assumption for page width is 600 pixels.) Place all your page content within the TD container. Voila, no more Wall o' Text.

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, but what about the vertical dimension?

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.

Except for absolute positioning, an advanced concept that is part of the HTML 4 specification (not very reliably implemented in current browsers), tables are the only way to achieve vertical centering.

Sample cover from eSenior, a project in the Final Seminar class of 2000.

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 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 last week), 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.

4.2 | FRAMES

Frames are among Netscape Communications' most ambitious additions to conventional HTML. Frames subdivide the browser window into what are in effect other browser windows, each displaying a URL or Web page.

In part this development answers the complaint that the Web is too disorienting. With frames, part of the screen can remain static as other parts change. This stable "ledge" could contain a table of contents, context-sensitive help, or just an identifying mark. Frame pages may thus enclose and exhibit other pages. This effect adds a new dimension to hypertext linking in HTML, allowing destination points to become visible before the reader has left the original context entirely behind.

Since an entire frame page may be called up as subframe of another such page, the potential for recursion is very high. You could end up with windows within windows within windows. Frames add considerably to the sophistication--and sometimes the frightening complexity--of Web documents.

Which brings us to the cynic's view. Perhaps the motivation behind frames is simply commercial: using this technique, advertisers can keep their messages in front of Web surfers even as they cruise from site to site. It has always been possible to include banner ads on Web pages without using frames, but frames make this task a great deal easier.

We've met designers who swear by frames and others (perhaps more numerous) who hate them with a passion. Like them or not, though, frames represent an important part of Web publishing.

A Generalized Frame Document

<HTML>     <HEAD>     </HEAD>     <FRAMESET>                 <FRAME>                 <FRAME>     </FRAMESET> </HTML>

A frame document has no BODY container: this element is replaced by the FRAMESET container. No tags useable inside a BODY container (IMG, H, HR, etc.) may appear ahead of the FRAMESET tag. The browser will ignore the frames information if it finds any of these first.

Frames are thus an all-or-nothing proposition: you can't mix frames with other layout styles as you can tables, applets, plug-in movies, and other enhancements to standard HTML. Though of course, frames do contain standard HTML pages, on which the familiar rules still apply.

Frames make a difference. By implication, frame layout pages constitute a new class of HTML documents, a more general and abstract level of structure that is connected to the older forms, yet distinct from them. In this respect frames were ahead of their time. Since frames were introduced in 1996, many technologies have been developed to operate as supersets of conventional HTML--most notably scripting languages like JavaScript (see Week 7) and Extensible Markup Language or XML. If nothing else, learning about frames will broaden your Web publishing horizons.

You'll remember that in HTML tables, rows are specified with <TR> while columns are created simply by layering up table cells, without an explicit container.

Unlike in tables, the frame scheme allows both rows and columns to be specified, so the initial FRAMESET tag has attributes for COLS as well as ROWS. This is not particularly consistent, so notice the difference between tables and frames in this regard.

Of course, you can write frame layouts having only columns or only rows. These simpler layouts are in fact quite common on the Web.

Here is a very simple frame layout showing the basic principles of frames in action. A screenshot of the output appears at right. Click on it to see the actual page: we can't show it directly here because it's impossible to mix frames with conventional HTML.

A Simple Frame Layout
<frameset rows="50%,50%">   <frameset cols="50%,50%">     <frame src="demoA.htm">     <frame src="demoB.htm">   </frameset>   <frame src="demoC.htm"> </frameset>

In this example the screen is divided two ways, yielding three parts. The first division (the initial or outer frameset container) splits the screen into two horizontal strips or rows. The top row is then cut by a vertical line into two columns (this is the work of the second, embedded frameset container). The lower section of the screen remains undivided and is handled by the final frame tag.

Rows need not be specified before columns. We could have nested the elements the other way around, though this produces a different layout, as you can see.

Another Simple Frame Layout
<frameset cols="50%,50%">   <frameset rows="50%,50%">     <frame src="demoA.htm">     <frame src="demoB.htm">   </frameset>   <frame src="demoC.htm"> </frameset>

Here's a frameset with an uneven distribution of columns and rows (three columns and two rows). The contents of the outermost container (the FRAMESET for ROWS) are two more FRAMESET containers, each specifying three COLS. There must be one FRAME tag for each frame in the grid.

A More Complicated Frame Layout
<frameset rows="100,100">   <frameset cols="100,100,100">     <frame src="demoA.htm">     <frame src="demoB.htm">     <frame src="demoE.htm">   </frameset>   <frameset cols="100,100,100">     <frame src="demoB.htm">     <frame src="demoC.htm">     <frame src="demoA.htm">   </frameset> </frameset>

In designing a frames layout with both rows and columns, you first define one dimension of the grid (rows or columns) then work out the divisions within each of the primary units if subdivisions are needed. Every division of the page must be accounted for either by a frame tag or by an embedded frameset container.

The dimensions of frames may be set in three ways: in percentages (as in the first two of our examples), in absolute pixels, or with an asterisk (*) indicating that the frame in question will be sized in relation to the space available. Here's how the asterisk usage works:

<FRAMESET ROWS="120,*,55">

This frameset divides the screen horizontally into three sections, the topmost 120 pixels high, the lowest 55 pixels high, and the middle section whatever remains after these values are deducted from the total height of the active window. This approach might be used to place non-scrolling "ledges" at top and bottom and a scrolling window in the middle of the screen.

Like <TD> in tables, the solitary FRAME tag fills in the content of the subdivisions in a frame layout. Each frame is assigned a particular URL through the SRC attribute (and note that the same URL may be assigned to more than one frame). SRC in effect creates a view of an HTML page in one section of the current screen.

<FRAME> also has optional attributes:

NAME

This attribute gives the frame a designation that may be used with the TARGET attribute in the link anchor tag (see below).





MARGINWIDTH, MARGINHEIGHT

These attributes let you set (in pixels) the width or height of the gap between the frame border and the contents of the frame.





SCROLLING

By default scrollbars will appear within a frame if its contents exceed the available dimensions--for instance, if you were to access the (very long) page you are reading now in a frame only 100 pixels high. If you set SCROLLING to "NO," then scrollbars will not appear under any circumstances; likewise a "YES" value brings in scrollbars whether or not they are required. Note that scrollbars appear for both horizontal and vertical scrolling even if you only wish to scroll in one dimension; some consider this a flaw.





NORESIZE

This attribute is a so-called flag with no assigned value (like NOSHADE in the HR tag). If NORESIZE is included, then the frame in question will always have the same height and width--otherwise the user can "drag" the frame margins to change the relative size of the frame, decreasing the amount of screen space given to other frames. NORESIZE turns off a default "yes" condition: all frames may be resized by the reader unless you say otherwise.

When a Web page is displayed in a frame all its hypertexts links remain active, allowing the reader to call up other pages; but where do these other pages appear?

By default they show up in the same frame within which the link was activated, as in this example. You may, however, create links that arrive in frames other than the one containing the departure point. This is done by adding a TARGET attribute to the departure link anchor.

The value assigned to TARGET may be the NAME value assigned in <FRAME>. Consider this example, along with its frame layout:



"Table of Contents" Frame Layout
<frameset cols="20%,80%">     <frame src="demo_toc.htm" name="toc">     <frame src="demoA.htm" name="main"> </frameset>

Each of the two frames in this layout has a NAME attribute (though in this case only the second, "main," is actually called by its name). The links contained in the "toc" ("Table of Contents") frame all contain TARGET attributes referring to "main." For instance:

<a href="demoA.htm" target="main">FILE A</a>

By using TARGET in link anchors, you can cause a link to change the contents of a specified frame. Note however that links cannot be targeted to more than one frame at a time. To update more than one frame with a single mouseclick you'll need to use a scripting language such as JavaScript, discussed in Week 7.

Though you can use almost anything you want as a corresponding value for NAME and TARGET, a number of values are reserved for special functions. Each of these special values begins with the underscore character ( _ ):

_top

Replaces the current frames layout with a new window in which only the destination page appears (you can use this facility to let readers break out of the frameset).





_new

Like _top, this values create a fresh window, but it does not close the previous window. The new window stacks over the old one. This can be a valuable technique, provided your users understand what's going on.





_parent

Places the destination page in the "parent" of the current frame -- which has the same effect as "_top" unless there is more than one window open, in which case only the "parent" window is updated.





_self

Places the destination page in the frame containing the link: this is the default case.

Special NAME/TARGET values must be given in lowercase letters; though HTML is usually not case-sensitive, this is a crucial exception.

Frames have not met with universal praise. Unhappy users point out several areas of concern, most of which software designers have tried to address, though controversies continue:

Navigation

Readers have complained sharply that frames make the Back function terribly ambiguous. Before frames, Back meant "show me the page I was viewing before this one" -- which is still the case with frames pages, though with a very troublesome difference. Frustrated readers find that Back on a frames page applies to the entire page (or layout), not just to the frame most recently updated. Having asked for a previous state of the layout (all the current frames plus an earlier version of one frame in particular) they see instead whatever page they were viewing before they accessed the frames layout--usually a page showing none of the previously visible frames.





Escaping From Frames

Users often want to view a page presented within a frame without that frame. In the old days, you had to add a link to your page with a TARGET="_top" attribute to accomplish this. Netscape Navigator includes a feature called Open Page in New Window. Microsoft Internet Explorer does not include such a feature.





Proliferating Markup

Inevitably, frames add complexity to Web markup. Working on a frames project may entail making interdependent changes on the frames layout page as well as several other pages invoked by various links. It is particularly difficult to view the source of a page within a frames layout; View Source in Netscape Navigator shows only the markup for the frameset page (though at least in Windows, the equivalent command in Internet Explorer shows markup for the component page).





Ugliness

For those not fond of thick gray lines, the original frames implementation was notably unattactive. However, Microsoft added the ability to change or suppress the frames borders in Internet Explorer, prompting Netscape to do the same in Navigator 3.0. Both browsers now support a FRAMEBORDER attribute in both the FRAMESET container and the FRAME tag, allowing the author to set the width of frame border lines, including a 0 setting for no visible borders. There is also now a BORDERCOLOR attribute that enables border divisions in colors other than battleship gray.





Scrolling

Though individual frames within the layout may scroll, the layout as a whole may not. This is a substantial difference from tables, which may contain more elements than are visible on the screen at once--a frame layout is confined to the limits of the screen, like it or not.

Some designers have given up on frames altogether, moving toward the more unified, multi-column structures common in so-called portal sites like Yahoo and Netscape. Meanwhile others have attempted to retain the structural power of frames--particularly the ability to construct a compound page from several separate markup files--without incurring all the mess and bother of multiple scrolling windowpanes.

One solution lies in server-side integration schemes such as Microsoft's Active Server Pages (ASP) or Allaire's ColdFusion application server. Arrangements like these intercept traffic that would normally go to the HTTP server. Paying attention to special, non-HTML tags, the intermediary program stitches together a customized markup that may include results of calculations, database queries, or fragments of HTML files.

To see a simple example of this technique, have a look at our alternative class entry page, designed for delivery via a ColdFusion server. Compare the ordinary entry page and note the major difference: in the ColdFusion version, both the table of contents and the main page scroll together. In the old-fashioned HTML version, the contents section scrolls separately.

END OF NOTES FOR WEEK 4

Return to Top of Page

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