Web Developer® -- Design Diary -- June 27, 1996

a Thursday feature

Using Tables and Server-Side Includes to Approximate Your Frames Design for the Frames-Impaired

by Lori Hylan

Last week's column mentioned that there were four options for dealing with the frames-impaired. This week we're going to go through the steps required to implement Option 4 (give users pages that visually approximate the frames pages, but that don't actually use frames). Again, you'll need access to an older version of Navigator or Internet Explorer, or some other browser that doesn't handle frames.
If you'll remember from last week, implementing Option 3 for the Thumper page offered the frames-impaired all the content available in the frames document, but it did so by duplicating that content--meaning that two different documents had to be updated whenever there were changes.
If we only wanted to update one document, we could offer the "options" text in the NOFRAMES area and link out to the tourdates.html, album.html, etc. files. The only problem in this case is that the individual files wouldn't have the Thumper logo or anything else on them to indicate that they belonged together.
So what we really need to do is somehow create pages that include the content of the header, main, and options frames--content that is updated whenever the documents in these frames are updated. What we need are a few server-side includes.
Files with server-side includes in them carry a .shtml file extension, rather than .html or .htm. (Your server needs to be told to support server-side includes; check with your System Administrator on this.) A simple server-side include looks like this:

In essence, a server-side include functions like an alias, pointing to the real file. This is what makes the content in your NOFRAMES area update automatically whenever you update the included file.
It also means that if you include several files consecutively, you will have several <HTML> and <BODY> tags. If the <BODY> tags have conflicting specifications, you're asking for trouble. There are two solutions: Either remove all the <HTML> and <BODY> tags from the included documents (this is the preferable solution, but it isn't always possible), or make sure that all the <BODY> tags are identical. We're going to do the the latter--otherwise known as taking the easier-to-manage way out--in our example.
The "Shtemlization" of the Thumper Home Page
I want to create a noframes version of the Thumper Home Page that will include all the stuff that's in the frames version--i.e., the logo, the press photo, the tour dates, the options, and information about the music, the members, and the album. I'd also like it to look as much like the frames version as possible, which means that the former four items will stay on the page at all times, and the latter three will change as the user clicks on different options.
The first thing we'll do is copy thumper4.html to thumper5.shtml (note that thumper5 ends in shtml) and delete everything between the <NOFRAMES></NOFRAMES> tags. We're going to reassemble our noframes area using server-side includes within a table, like this (explanation follows):
<html>
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#232182">
<center>
<table width=550>
<tr valign=top align=left>
<td width=130>

<p>

</td>

<td width=420>

<p>

<p>

</td>
</tr>
</table>
</center>
</body>
</html>
I specified the first column in the table to be 130 pixels wide to coincide with the width of the first column in the frameset (<FRAMESET COLS="130,*">); 550 is a random width that's less than 640. The #includes say "virtual" instead of "file" because #include file will only work with files that are in the same directory or a subdirectory of it. With #include virtual, you can specify an entire URL (instead of just a path), or--as I did--the entire path from the root directory (I do this, by the way, so that I don't have to update my links when the columns are archived).
You'll notice that instead of merely calling on the images I wanted (press-sm.jpg and thumperhead.gif), I called on HTML files that contain them. This is because--unfortunately--#includes cannot reference image files directly. You'll also notice that I didn't just use the header.html file that was specified in the frameset. Remember that I said all the <BODY> tags had to be identical? The original header.html file had a red background, so I created a noframes_header.html file that had a white background and black text.
The noframes_options.html file is similar to noframes_header.html. I needed an options file that was slightly different than the original, so I copied options.html to create noframes_options.html, changed each of the links to read .shtml instead of .html, and removed all the target="main"s. [NB: It is not absolutely necessary to have a separate options.html file to deal with includes. One options.html that linked out to .shtml versions of your files would do the trick, but it would require that you insert a "dummy" frame in your FRAMESET. What this means in practical terms is that you create one less document, but with every click you create huge numbers of empty frames (unfortunately, the dummy frames are cumululative).]
OK, that covers everything in the example above--but you may have noticed that noframes_options is now linking to a bunch of SHTML files that don't yet exist. We need to create "shteml" versions of members.html, info.html and album.html. Set them up like the example above, with only the "main" information changing each time (info.shtml will be identical to the example above). Each of the files should be named exactly as its HTML counterpart, only with a .shtml extension. (Remember, although we are creating extra files here, we still only have to update the original HTML file in order for both frames-capable and frames-impaired users to see any changes.)
Violá! You now have a document that will look virtually the same whether you view it with a frames-capable or a frames-impaired browser--and, as an added bonus, you have a directory full of both .html and .shtml files! <g> Just remember that when you make changes, make them to the .html files, and you'll be fine.
----
Peter Hegedus's input in the writing of this column is gratefully acknowledged.
----
Past installments of Design Diary