This document answers questions asked frequently by web authors. While its focus is on HTML-related questions, this FAQ also answers some questions related to CSS, HTTP, JavaScript, server configuration, etc.
This document is maintained by Darin McGrew <darin@htmlhelp.com> of the Web Design Group, and is posted regularly to the newsgroup comp.infosystems.www.authoring.html. It was last updated on April 26, 2007.
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<br>
<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 older versions of
Netscape Navigator have problems with them if you don't explicitly close
your TR, TD, and
TH elements.
To avoid problems, include every </tr>,
</td>, and </th> tag, even
though the HTML specifications don't require them.
Also, older versions of Netscape Navigator have problems with tables that are nested extremely deeply (e.g., tables nested ten deep). To avoid problems, avoid nesting tables more than a few deep. You may be able to use the ROWSPAN and COLSPAN attributes to minimize table nesting.
Finally, be especially sure to validate your markup whenever you use nested tables.
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="[URL]">
<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>In your HTML, use
<div class="center">
<table>...</table>
</div>In your CSS, use
div.center {
text-align: center;
}
div.center table {
margin-left: auto;
margin-right: auto;
text-align: 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:
The table in this example will float to the right.
<table align="right">...</table>
This text will wrap to fill the available space to the left of (and if the
text is long enough, below) the table.
<br clear="right">
This text will appear below the table,
even if there is additional room to its left.
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.
<TABLE WIDTH="100%"> use the full browser width?Graphical browsers leave a narrow margin between the edge of the display area and the content.
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.
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.
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 accomodate 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 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. Even with correct syntax, nested tables may not display correctly in older versions of Netscape Navigator.
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.
All rights reserved.