Can I nest tables within tables?
How can I use tables to structure forms?
How do I center a table?
How do I align a table to the right (or left)?
Can I use percentage values for <TD WIDTH=...>?
Why doesn't
<TABLE WIDTH="100%"> use the full browser width?Why is there extra space before or after my table?
Are there any problems with using tables for layout?
Section 7: HTML Tables
7.1. How do I make a table which looks good on non-supporting browsers?
See Alan Flavell's document on tables for a good discussion at URL: http://ppewww.ph.gla.ac.uk/%7Eflavell/www/tablejob.html.
7.2. Can I nest tables within tables?
Yes, a table can be embedded inside a cell in another table. Here's a simple example:
<table>
<tr>
<td>this is the first cell of the outer table</td>
<td>this is the second cell of the outer table,
with the inner table embedded in it
<table>
<tr>
<td>this is the first cell of the inner table</td>
<td>this is the second cell of the inner table</td>
</tr>
</table>
</td>
</tr>
</table>
The main caveat about nested tables is that Netscape has problems with them if you don't close your TD and TR tags meticulously. You're best advised to include every </TD> and </TR>, even though the HTML spec doesn't require them; otherwise Netscape users may not be able to view your page.
7.3. How can I use tables to structure forms?
Small forms are sometimes placed within a TD element within a table. This can be a useful for positioning a form relative to other content, but it doesn't help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire table must be within the form. You cannot start a form in one TH or TD element and end in another. You cannot place the form within the table without placing it inside a TH or TD element. You can put the table inside the form, and then use the table to position the INPUT, TEXTAREA, SELECT, and other form-related elements, as shown in the following example.
<FORM ACTION="<var>[URL]</var>">
<TABLE BORDER="0">
<TR>
<TH>Account:</TH>
<TD><INPUT TYPE="text" NAME="account"></TD>
</TR>
<TR>
<TH>Password:</TH>
<TD><INPUT TYPE="password" NAME="password"></TD>
</TR>
<TR>
<TD> </TD>
<TD><INPUT TYPE="submit" NAME="Log On"></TD>
</TR>
</TABLE>
</FORM>
The "correct" way of doing it is <TABLE ALIGN=CENTER>, but this doesn't work in several popular browsers. Put <CENTER>; around the entire table for these browsers.
This causes some problems with browsers that do support CENTER but not tables, such as Lynx. In these browsers, the contents of the cells are now displayed centered, which is not what is intended. To avoid this, you can put the cell's contents in <P ALIGN=left> or <DIV ALIGN=left> depending on the amount of text in the cell.
7.5. How do I align a table to the right (or left)?
You can use <TABLE ALIGN="right"> to float a table to the right. (Use ALIGN="left" to float it to the left.) Any content that follows the closing </TABLE> tag will flow around the table. Use <BR CLEAR="right"> or <BR CLEAR="all"> to mark the end of the text that is to flow around the table, as shown in this example:
<TABLE ALIGN="right">...</TABLE>
The table will float to the right.
This text will appear to the left of the table.
<BR CLEAR="right">
This text will appear below the table,
even if there is additional room to its left.
7.6. Can I use percentage values for <TD WIDTH=...>?
The HTML 3.2 and HTML 4.0 specifications allow only integer values (representing a number of pixels) for the WIDTH attribute of the TD element. However, the HTML 4.0 DTD allows percentage (and other non-integer) values, so an HTML validator will not complain about <TD WIDTH="xx%">.
It should be noted that Netscape and Microsoft's browsers interpret percentage values for <TD WIDTH=...> differently. However, their interpretations (and those of other table-aware browsers) happen to match when combined with <TABLE WIDTH="100%">. In such situations, percentage values can be used relatively safely, even though they are prohibited by the public specifications.
7.7. Why doesn't <TABLE WIDTH="100%"> use the full browser width?
Graphical browsers leave a narrow margin between the edge of the display area and the content. For information on how you can specify that the browser omit these margins, see the answer to the question "How do I eliminate the margins around my page?"
Also note that Navigator always leaves room for a scrollbar on the right, but draws the scrollbar only when the document is long enough to require scrolling. If the document does not require scrolling, then this leaves a right "margin" that cannot be removed.
7.8. Why is there extra space before or after my table?
This is often caused by invalid HTML syntax. Specifically, it is often caused by loose content within the table (i.e., content that is not inside a TD or TH element). There is no standard way to handle loose content within a table. Some browsers display all loose content before or after the table. When the loose content contains only multiple line breaks or empty paragraphs, then these browsers will display all this empty space before or after the table itself.
The solution is to fix the HTML syntax errors. All content within a table must be within a TD or TH element.
7.9. Are there any problems with using tables for layout?
On current browsers, the entire table must be downloaded and the dimensions of everything in the table must to be known before the table can be rendered. That can delay the rendering of your content, especially if your table contains images without HEIGHT or WIDTH attributes.
If any of your table's content is too wide for the available display area, then the table stretches to accommodate the oversized content. The rest of the content then adjusts to fit the oversized table rather than fitting the available display area. This can force your readers to scroll horizontally to read your content, or can cause printed versions to be cropped.
For readers whose displays are narrower than the author anticipated, fixed-width tables cause the same problems as other oversized tables. For readers whose displays are wider than the author anticipated, fixed-width tables cause extremely wide page margins, wasting much of the display area. For readers who need larger fonts, fixed-width tables can cause the content to be displayed in short choppy lines of only a few words each.
Many browsers are especially sensitive to invalid syntax when tables are involved. Correct syntax is especially critical. See the answer to "How can I check for errors?" Even with correct syntax, nested tables may not display correctly in Netscape. See the answer to "Can I nest tables within tables?" for what you can do about that.
Some browsers ignore tables, or can be configured to ignore tables. These browsers will ignore any layout you've created with tables. Also, search engines ignore tables. Some search engines use the text at the beginning of a document to summarize it when it appears in search results, and some index only the first n bytes of a document. When tables are used for layout, the beginning of a document often contains many navigation links that appear before than actual content.
Many versions of Navigator have problems linking to named anchors when they are inside a table that uses the ALIGN attribute. These browsers seem to associate the named anchor with the top of the table, rather than with the content of the anchor. You can avoid this problem by not using the ALIGN attribute on your tables.
If you use tables for layout, you can still minimize the related problems with careful markup. Avoid placing wide images, PRE elements with long lines, long URLs, or other wide content inside tables. Rather than a single full-page layout table, use several independent tables. For example, you could use a table to lay out a navigation bar at the top/bottom of the page, and leave the main content completely outside any layout tables.
The use of tables for layout is explored in detail at URL: http://www.dantobias.com/webtips/tables.html.
