'Tables' have three common uses in web pages: (1) to enable a 'stable' page layout that will not change significantly when viewed on monitors with different screen resolutions; (2) to arrange different elements precisely in relation to one another within a page design by using 'sub-tables'; and (3) to present an array of related data in column-cell format. The second and third uses are similar to how tables are used in word-processors; the first is primarily used with web pages.(Left): Shot from a 4:3-ratio monitor with an 800x600 display setting
(Center): 4:3-ratio monitor with a 1024x768 display (as on many university computers)
(Right): 16:10-ratio 'widescreen' monitor with an 1280x800 display (as on many laptops)
Notice how the page content 'scales' to the available screen width.
(Click images to see original sizes; the browser used was Internet Explorer 8)
How to Create A Simple Page-Layout TableCreating a simple page-layout table is easy. One could, for example, use the 'view source' command to see the underlying HTML code for this page to see how it is done. The procedure is also described below.
All tables begin by turning on the 'table command' and giving a parameter for the table width. For the layout of this page the command was <Table width=800> (begun at the top of the page coding and turned off as the last part of the page coding).
Tables need to have at least one 'table row' (TR), which would be followed by at least one 'table detail' (TD). For a simple page layout in which the whole page would be inside a single table with the objective of limiting the displayable width of the page, the 'TD' would usually be the same width as the table itself. The coding for those two elements on this page was <TR> <TD width=800>. As the page-display table should be centered on the screen, a <center> command should precede the table coding. Without this the table would be aligned to the left of the page, rather than in the middle. For the coding of all the above commands, it does not matter if upper, mixed or lower case is used.
After the table has been turned on, the regular content of the web page would be added. At the very end of the page, the table should be turned off by putting </TD>, </TR> </TABLE>, again as can be seen at the bottom of this page via the 'view source' command.
Notice the resulting similarity of the two following images which have used an 800-width table to standardize the display. The page widths, as limited by the table, are almost exactly the same. The main difference is (a) a slight difference in the page 'lengths,' e.g. the number of visible text lines from top to bottom, and (b) a slightly larger size of all the displayable elements in the image at left, since an 800x600 display on a 4:3 monitor will show everything proportionately larger than a 1280x800 display on a 16:10 monitor.
(Left): 4:3-ratio monitor with an 800x600 display
The '800' Page Layout Width and Page 'Printability'The simple table described above for basic page layout can also be any other width, either shorter or wider than '800'. However, an additional advantage of the '800' width (beyond being readable on any monitor setting) is that it matches fairly accurately the 'printability' of web pages, especially those which include images (whether in sub-tables or not), charts, etc. Most printers (assuming they are printing on A4 paper in 'portrait' mode) cannot print data which extends beyond a page width of 800 (sometimes even less than 800). Thus a 800-width (or less) table would 'ensure' that all the visible data of a page would be printable. This is why the PK5 paper template has a tabled page width of 800.
This 'printability' is only approximate, however, as printers differ in
what they are able to produce, so that using 'Print Preview' to check your
page design is essential whenever your page includes images as well as
(2) Using (sub-)Tables to Align Design Elements on a Web PageA web page may include a number of different sub-tables as well, if needed for design purposes. A number of examples of such tables are given in the file on Using Images in Web Pages, particularly for having the page text flow around images in sub-tables on the right or left side of the page. Another example of sub-tables is the webform Quiz #2 Thank-you note, in which there a sub-table is used to center the thank-you text box, with different TD elements for the images on either side plus the text box in the middle.
When designing sub-tables, measurements can be given either as exact pixels (such as '800' for the width of this page) or as percentages. However, once a top-level table has been established, the percentages of sub-tables will always be percentages of the available space in the table. If a page has been restricted to an 800 width, then a table with a '50%' width would display as "50% of 800", not as 50% of the entire viewable screen.
Similarly, if using exact pixels, all of widths defined in each TD must be less than the width of the top-level table. In other words, for an 800-with overall table page, a sub-table must be less than 800 in width. Usually it would be considerably less: a flow-around image table would probably be 400 or less, as 400 would already consume half of the available 800 width. In short, all subtable widths and their TD sub-widths must be able to fit within the space available in the overall page in order for the table to display properly. If sub-table widths, or the widths of the images inside their TD are larger than the overall page table width itself, the display results will vary radically among different web browsers as the browsers try to resolve the incompatible mathematics.
NOTE: Cases in Which Sub-tables Should Preferably NOT Be UsedSub-tables mainly need to be used in only two cases: (1) where text flows around an image or table which is aligned to the right or left of the page; and/or (2) where two are more images are centered beside each other with captions that should be centered beneath each individual image. In other cases, such as a large image which is in between paragraphs of text on the page (see example here); or two or more images aligned horizontally with a shared, centered caption for all of the images (see example here); simply using the CENTER command is preferable to using a sub-table.
(3) Presenting Data Arrays in Table FormatTables which are used for presenting statistical or similar data will require a bit more coding. If a table has already been created in Word (or other word processors), it may be simpler to use the word processor's "convert to HTML" command and then copy only the table part of the coding to the new web page, instead of re-creating an HTML table for the same data.
For the table below (where the details are only for example), the table itself is first defined as comprising 80% of the available space on the page (e.g. 80% of '800') with a center-alignment. It has a border of '3', with a bordercolor of 'blue' to show more clearly the table boundaries and the columns and cells of information.
There is a table 'caption' (title), followed by a table row (TR) which includes four table 'headers' (TH). A table 'header' cell will always be in boldface. The data is then presented in four additional table rows (TR), each of which includes four table details (TD). The width of each TD is 20%; with all four totalling 80%, the exact space available since the overall table has been designed with a width of 80%.
Notice that each TD must include a command for align=center if you wish to have the data centered in the cell; otherwise the default is "left." If you wish a different font face or size than that of the page itself, this must also be defined for each TD.
Use 'view source' to examine how the table below has been produced:
(4) Varying the Fonts, Colors and Sizes of Data TablesThe font faces, sizes, and both font and cell background colors may be specified within each <TD> unit of each table. Note that all specifications must be defined separately for each TD unit; one setting will not 'carry' across different TD units of the same table.
In the example below, a different font face has been used for each row of the table, with "Franklin Gothic Medium" being used for the first row, "Monotype Corsiva" for the second row, "Comic Sans MS" for the third row, and "Consolas" for the fourth row (all of these fonts are part of the standard installation of Microsoft Office 2003).
Different colors have also been used for both some of the cell backgrounds and cell texts, with the top line having combinations of white text on a navy background; red text on a yellow background; yellow text on a green background; and green text on a gold background, respectively. The third data line uses a yellow text on a red background for the first and fourth cells, and the default black text on a white background for the second and third cells. The fourth line uses light gray as the background for the two middle cells (to provide more contrast for the white cell backgrounds just above). Students may thus use combinations of text colors and possibly also cell backgrounds as desired to highlight or distinguish certain categories of information within a table.
While the tables may appear at first to be complicated to produce, once a simple table has been created (such as the one above), one can use a text editor's "search and replace" function to insert quickly additional detail about cell backgrounds, font styles and font colors within the table. The table below, as one can notice from 'View Source', is essentially the same as the table above, but with extra information added to certain TD units for the different fonts and colors.
If a complicated table has already been produced in a word processor
such as Microsoft Word, for example, rather than manually re-creating the
table in HTML is would often be simpler to use Word's own "convert to
HTML" function, then go to the underlying source code for the resulting
page, and then copy-pasting the table coding to your web paper, possibly
with minor additional editing to get the fonts and sizes of the table
information consistent with the rest of the paper.
More complicated tables may also be produced, but the examples given here and on the other PK5 pages in which tables have been used should easily satisfy all normal student requirements. Should you wish to do more advanced work with tables, ask John for guidance as needed.