I am afraid that by the end of this lab many of you will find yourselves thinking (or even saying) "unkind things" about HTML, PageSpinner, this course, your instructor...
There are two reasons for this fear, and I would like to try to warn you about them ahead of time in hopes of reducing the frustration some of you will probably experience.
The first problem is something I have been warning you about for a while now. When you make a mistake in an HTML file, browsers just do the best they can to display something reasonable rather than producing some form of error report. So far, this feature of browsers has probably helped you avoid frustration. With the simple subset of HTML we have been using, the browser has been pretty successful at producing reasonable results given incorrect HTML and has thereby saved you the effort required to get everything just right.
Unfortunately, HTML tables are not so simple. If you make a mistake in a table, the browser is unlikely to be able to guess what you really meant. Instead, you will find yourself looking at tables with more or fewer rows or columns than expected or cells in strange places. Worst of all, you may find yourself looking for tables or other parts of a web page that disappear completely. When this happens, you will suddenly wish that your browser displayed some cryptic message when it got confused. The messages that Metrowerks produced when your Java code was wrong last week might not have meant much to you, but at least Metrowerks usually pointed you at the line in the file that was incorrect!
The bad news is that this is only half the bad news. The other problem with tables is that some of the table attributes you can specify are really only "hints". In particular, when you specify the width or height of a cell, you will find that you are really negotiating more that specifying. Netscape's "counteroffers" may surprise you. For example, specifying that a column should be wider may sometimes actually result in it getting narrower.
There are several things you can do to maintain your composure as you work on tables.
will be much easier to correct or modify than something like:<TABLE> <TR> <TH> YEAR </TH> <TH> MINIMUM </TH> <TH> AVERAGE </TH> </TR> <TR> <TH> 1970 </TH> <TD> 10,039 </TD> <TD> 13,290 </TD> </TR> . . . </TABLE>
Trust me. The extra time it takes to keep your HTML nicely formatted as you type it in will save you time and pain in the long run.<TABLE> <TR> <TH> YEAR </TH> <TH> MINIMUM </TH> <TH> AVERAGE </TH> </TR> <TR> <TH> 1970 </TH> <TD> 10,039 </TD> <TD> 13,290 </TD> </TR> . . . </TABLE>
One extra bit of HTML that might help you keep your HTML clear enough to fix easily is the HTML comment. A comment is an HTML tag that the browser ignores completely. It allows you to put annotations on your HTML intended to clarify your HTML to someone reading it directly rather than through a browser. The format of a comment is:
Putting comments like:<!-- Any text you want to type goes here -->
at the appropriate point in your HTML can make life much easier.<!-- The first row of this table begins here -->
To make sure you practice using comments at least a little bit, we will require you to add a comment including your name and the day and time of the lab you are scheduled to attend to the beginning of each HTML file you create for the remainder of the semester. In addition to giving you practice, this will help us avoid misplacing your work as we grade it.