then
the default for the table element is RULES=ALL, except if _n=0_
for which RULES=NONE is appropriate.
CELLSPACING
This attribute is intended for backwards compatibility with
deployed user agents. It specifies the space between the table
frame and the first or last cell border for each row or column,
and between other cells in the table. See standard units.
Greater control will be possible using style sheet languages.
CELLPADDING
This attribute is intended for backwards compatibility with
deployed user agents. It specifies the amount of space between
the border of the cell and its contents both above/below, and
Raggett Experimental [Page 15]
RFC 1942 HTML Tables May 1996
left//right. See standard units. Greater control will be
possible using style sheet languages.
If a fixed width is set for the table or column, the CELLSPACING and
CELLPADDING may demand more space than assigned. Current practice is
for the latter to take precedence over WIDTH attributes when a
conflict occurs, although this isn't required by this specification.
Table Captions
The optional CAPTION element is used to provide a caption for the
table. Both start and end tags are required.
ID, CLASS, LANG and DIR
See earlier description of common attributes.
ALIGN
This may be used to control the placement of captions relative
to the table. When present, the ALIGN attribute should have one
of the values: TOP, BOTTOM, LEFT and RIGHT. It is recommended
that the caption is made to fit within the width or height of
the table as appropriate. The default position of the caption is
deliberately unspecified.
Note the ALIGN attribute is overused in HTML, but is retained
here for compatibility with currently deployed browsers.
The COLGROUP Element
The COLGROUP element acts as a container for a group of columns, and
allows you to set default properties for these columns. In the
absence of a COLGROUP element, all columns in the table are assumed
to belong to a single column group. Each COLGROUP element can
contain zero or more COL elements. COLGROUP requires a start tag,
but the end tag may be omitted. This is useful when defining a
sequence of COLGROUP elements, e.g.
COLGROUP elements can be used with the following attributes:
ID, CLASS, LANG and DIR
See earlier description of common attributes.
SPAN
A positive integer value that specifies a default for how many
columns are in this group. This attribute should be ignored if
the COLGROUP element contains one or more COL elements. It
provides a convenient way of grouping columns without the need
to supply COL elements.
WIDTH
Specifies a default width for each of the grouped columns, see
standard units. In addition, the "*" suffix denotes relative
widths, e.g.
width=64 width in screen pixels
width=0.5* a relative width of 0.5
Relative widths act as constraints on the relative widths of
different columns. If a COLGROUP element specifies a relative
width of zero, all of the columns in the group should be set to
their minimum widths, unless they are associated with a COL
element with an overriding WIDTH attribute. When widths are
Raggett Experimental [Page 17]
RFC 1942 HTML Tables May 1996
given in absolute units, the user agent can use these to
constrain the width of the table. The "*" suffix is used to
simplify importing tables from the CALS representation.
ALIGN, CHAR, CHAROFF and VALIGN
Specify values for horizontal and vertical alignment within
table cells. See inheritance order of alignment properties.
The COL Element
This optional element is used to specify column based defaults for
table properties. It is an empty element, and as such has no
content, and shouldn't be given an end tag. Several COL elements may
be given in succession. COL attributes override those of the parent
COLGROUP element.
ID, CLASS, LANG and DIR
See earlier description of common attributes.
SPAN
A positive integer value that specifies how many columns this
element applies to, defaulting to one. In the absence of SPAN
attributes the first COL element applies to the first column,
the second COL element to the second column and so on. If the
second COL element had SPAN=2, it would apply to the second and
third column. The next COL element would then apply to the
fourth column and so on. SPAN=0 has a special significance and
implies that the COL element spans all columns from the current
column up to and including the last column. Note that a COL SPAN
does not define a group. It is merely a way to share attribute
definitions.
Raggett Experimental [Page 18]
RFC 1942 HTML Tables May 1996
WIDTH
Specifies the width of the columns, see standard units. If the
element spans several columns then the WIDTH attribute specifies
the width for each of the individual columns - not the width of
the span. In addition, the "*" suffix denotes relative widths,
e.g.
width=64 width in screen pixels
width=0.5* a relative width of 0.5
Relative widths act as constraints on the relative widths of
different columns. If a COL element specifies a relative width
of zero, the column should always be set to its minimum width.
When widths are given in absolute units, the user agent can use
these to constrain the width of the table. The "*" suffix is
used to simplify importing tables from the CALS representation.
ALIGN, CHAR, CHAROFF and VALIGN
Specify values for horizontal and vertical alignment within
table cells. See inheritance order of alignment properties.
Table Head, Foot and Body Elements
Tables may be divided up into head and body sections. The THEAD and
TFOOT elements are optional, but one or more TBODY elements are
always required. If the table only consists of a TBODY section, the
TBODY start and end tags may be omitted, as the parser can infer
them. If a THEAD element is present, the THEAD start tag is
required, but the end tag can be omitted, provided a TFOOT or TBODY
start tag follows. The same applies to TFOOT.
Note: This definition provides compatibility with tables created
for the older model, as well as allowing the end tags for THEAD,
TFOOT and TBODY to be omitted.
Raggett Experimental [Page 19]
RFC 1942 HTML Tables May 1996
The THEAD, TFOOT and TBODY elements provide a convenient means for
controlling rendering. If the table has a large number of rows in
the body, user agents may choose to use a scrolling region for the
table body sections. When rendering to a paged device, tables will
often have to be broken across page boundaries. The THEAD, TFOOT and
TBODY elements allow the user agent to repeat the table foot at the
bottom of the current page, and then the table head at the top of
the new page before continuing on with the table body.
TFOOT is placed before the TBODY in the markup sequence, so that
browsers can render the foot before receiving all of the table data.
This is useful when very long tables are rendered with scrolling
body sections, or for paged output, involving breaking the table
over many pages.
Each THEAD, TFOOT and TBODY element must contain one or more TR
elements.
ID, CLASS, LANG and DIR
See earlier description of common attributes.
ALIGN, CHAR, CHAROFF and VALIGN
Specify values for horizontal and vertical alignment within
table cells. See inheritance order of alignment properties.
Table Row (TR) elements
The TR or table row element acts as a container for a row of table
cells. The end tag may be omitted.
ID, CLASS, LANG and DIR
See earlier description of common attributes.
ALIGN, CHAR, CHAROFF and VALIGN
Specify values for horizontal and vertical alignment within
table cells. See inheritance order of alignment properties.
Raggett Experimental [Page 20]
RFC 1942 HTML Tables May 1996
Table Cells: TH and TD
TH elements are used to represent header cells, while TD elements
are used to represent data cells. This allows user agents to render
header and data cells distinctly, even in the absence of style
sheets.
Cells can span multiple rows and columns, and may be empty. Cells
spanning rows contribute to the column count on each of the spanned
rows, but only appear in the markup once (in the first row spanned).
The row count is determined by the number of TR elements. Any rows
implied by cells spanning rows beyond this should be ignored.
If the column count for the table is greater than the number of
cells for a given row (after including cells for spanned rows), the
missing cells are treated as occurring on the right hand side of the
table and rendered as empty cells. If the language context indicates
a right to left writing order, then the missing cells should be
placed on the left hand side.
It is possible to create tables with overlapping cells, for
instance:
Raggett Experimental [Page 21]
RFC 1942 HTML Tables May 1996
which might look something like:
/-----------\
| 1 | 2 | 3 |
| |-------|
| | 4 | |
|---|...|---|
| 5 : | 6 |
\-----------/
In this example, the cells labelled 4 and 5 overlap. In such cases,
the rendering is implementation dependent.
The AXIS and AXES attributes for cells provide a means for defining
concise labels for cells. When rendering to speech, these attributes
may be used to provide abbreviated names for the headers relevant to
each cell. Another application is when you want to be able to later
process table contents to enter them into a database. These
attributes are then used to give database field names. The table's
class attribute should be used to let the software recognize which
tables can be treated in this way.
ID, CLASS, LANG and DIR
See earlier description of common attributes.
AXIS
This defines an abbreviated name for a header cell, e.g. which
can be used when rendering to speech. It defaults to the cell's
content.
AXES
This is a comma separated list of axis names which together
identify the row and column headers that pertain to this cell.
It is used for example when rendering to speech to identify the
cell's position in the table. If missing the user agent can try
to follow up columns and left along rows (right for some
languages) to find the corresponding header cells.
NOWRAP, e.g. |
The presence of this attribute disables automatic wrapping of
text lines for this cell. If used uncautiously, it may result in
excessively wide cells. This attribute is defined for backwards
compatibility with deployed user agents. Greater control is
possible with associated style sheet languages (for example for
control over overflow handling).
Raggett Experimental [Page 22]
RFC 1942 HTML Tables May 1996
ROWSPAN, e.g. |
A positive integer value that defines how may rows this cell
spans. The default ROWSPAN is 1. ROWSPAN=0 has a special
significance and implies that the cell spans all rows from the
current row up to the last row of the table.
COLSPAN, e.g. |
A positive integer value that defines how may columns this cell
spans. The default COLSPAN is 1. COLSPAN=0 has a special
significance and implies that the cell spans all columns from
the current column up to the last column of the table.
ALIGN, CHAR, CHAROFF and VALIGN
Specify values for horizontal and vertical alignment within
table cells. See inheritance order of alignment properties.
Note: It is recommended that implementors provide support for the
Netscape 1.1 WIDTH attribute for TH and TD, although this isn't part
of the current specification. Document authors are advised to use
the width attribute for the COL element instead.
Recommended Layout Algorithms
If the COLS attribute on the TABLE element specifies the number of
columns, then the table may be rendered using a fixed layout,
otherwise the autolayout algorithm described below should be used.
Fixed Layout Algorithm
For this algorithm, it is assumed that the number of columns is
known. The column widths by default should be set to the same size.
Authors may override this by specifying relative or absolute column
widths, using the COLGROUP or COL elements. The default table width
is the space between the current left and right margins, but may be
overridden by the WIDTH attribute on the TABLE element, or determined
from absolute column widths. To deal with mixtures of absolute and
relative column widths, the first step is to allocate space from the
table width to columns with absolute widths. After this, the space
remaining is divided up between the columns with relative widths.
The table syntax alone is insufficient to guarantee the consistency
of attribute values. For instance, the number of columns specified by
the COLS attribute may be inconsistent with the number of columns
implied by the COL elements. This in turn, may be inconsistent with
the number of columns implied by the table cells. A further problem
occurs when the columns are too narrow to avoid overflow of cell
contents. The width of the table as specified by the TABLE element or
COL elements may result in overflow of cell contents. It is
Raggett Experimental [Page 23]
RFC 1942 HTML Tables May 1996
recommended that user agents attempt to recover gracefully from these
situations, e.g. by hyphenating words and resorting to splitting
words if hyphenation points are unknown.
In the event that an indivisible element causes cell overflow, the
user agent may consider adjusting column widths and re-rendering the
table. In the worst case clipping may be considered if column width
adjustments and/or scrollable cell content are not feasible. In any
case if cell content is split or clipped this should be indicated to
the user in an appropriate manner.
Autolayout Algorithm
If the COLS attribute is missing from the table start tag, then the
user agent should use the following autolayout algorithm. It uses two
passes through the table data and scales linearly with the size of
the table.
In the first pass, line wrapping is disabled, and the user agent
keeps track of the minimum and maximum width of each cell. The
maximum width is given by the widest line. As line wrap has been
disabled, paragraphs are treated as long lines unless broken by
elements. The minimum width is given by the widest word or image etc.
taking into account leading indents and list bullets etc. In other
words, if you were to format the cell's content in a window of its
own, determine the minimum width you could make the window before the
cell begins to overflow. Allowing user agents to split words will
minimize the need for horizontal scrolling or in the worst case
clipping of cell contents.
This process also applies to any nested tables occuring in cell
content. The minimum and maximum widths for cells in nested tables
are used to determine the minimum and maximum widths for these tables
and hence for the parent table cell itself. The algorithm is linear
with aggregate cell content, and broadly speaking independent of the
depth of nesting.
To cope with character alignment of cell contents, the algorithm
keeps three running min/max totals for each column: Left of align
char, right of align char and un-aligned. The minimum width for a
column is then: max(min_left + min_right, min_non-aligned).
The minimum and maximum cell widths are then used to determine the
corresponding minimum and maximum widths for the columns. These in
turn, are used to find the minimum and maximum width for the table.
Note that cells can contain nested tables, but this doesn't
complicate the code significantly. The next step is to assign column
widths according to the available space (i.e. the space between the
Raggett Experimental [Page 24]
RFC 1942 HTML Tables May 1996
current left and right margins).
For cells which span multiple columns, a simple approach, as used by
Arena, is to evenly apportion the min/max widths to each of the
constituent columns. A slightly more complex approach is to use the
min/max widths of unspanned cells to weight how spanned widths are
apportioned. Experimental study suggests a blend of the two
approaches will give good results for a wide range of tables.
The table borders and intercell margins need to be included in
assigning column widths. There are three cases:
1. The minimum table width is equal to or wider than the available
space. In this case, assign the minimum widths and allow the
user to scroll horizontally. For conversion to braille, it will
be necessary to replace the cells by references to notes
containing their full content. By convention these appear before
the table.
2. The maximum table width fits within the available space. In this
case, set the columns to their maximum widths.
3. The maximum width of the table is greater than the available
space, but the minimum table width is smaller. In this case,
find the difference between the available space and the minimum
table width, lets call it W. Lets also call D the difference
between maximum and minimum width of the table.
For each column, let d be the difference between maximum and
minimum width of that column. Now set the column's width to the
minimum width plus d times W over D. This makes columns with
large differences between minimum and maximum widths wider than
columns with smaller differences.
This assignment step is then repeated for nested tables using the
minimum and maximum widths derived for all such tables in the first
pass. In this case, the width of the parent (i.e. enclosing) table
cell plays the role of the current window size in the above
description. This process is repeated recursively for all nested
tables. The topmost table is then rendered using the assigned widths.
Nested tables are subsequently rendered as part of the parent table's
cell contents.
If the table width is specified with the WIDTH attribute, the user
agent attempts to set column widths to match. The WIDTH attribute is
not binding if this results in columns having less than their minimum
(i.e. indivisible) widths.
Raggett Experimental [Page 25]
RFC 1942 HTML Tables May 1996
If relative widths are specified with the COL element, the algorithm
is modified to increase column widths over the minimum width to meet
the relative width constraints. The COL elements should be taken as
hints only, so columns shouldn't be set to less than their minimum
width. Similarly, columns shouldn't be made so wide that the table
stretches well beyond the extent of the window. If a COL element
specifies a relative width of zero, the column should always be set
to its minimum width.
HTML Table DTD
The DTD or document type definition provides the formal definition of
the allowed syntax for HTML tables.
1766 --
dir (ltr|rtl) #IMPLIED -- I18N text direction --">
Raggett Experimental [Page 26]
RFC 1942 HTML Tables May 1996
References
Arena
W3C's HTML3 browser, see http://www.w3.org/pub/WWW/Arena/.
Arena was originally created as a proof of concept demo for
ideas in the HTML+ specification that preceded HTML3. The
browser is now being re-implemented to provide a reference
implementation of HTML3 along with support for style sheets and
client-side scripting.
CALS
Continuous Acquisition and Life-Cycle Support (formerly
Computer-aided Acquisition and Logistics Support) (CALS) is a
Department of Defense (DoD) strategy for achieving effective
creation, exchange, and use of digital data for weapon systems
and equipment. More information can be found from the US Navy
CALS home page at http://navysgml.dt.navy.mil/cals.html
Raggett Experimental [Page 29]
RFC 1942 HTML Tables May 1996
HTML 2.0 (RFC1866)
Hypertext Markup Language Specification Version 2.0 by T.
Berners-Lee and D. Connolly, November 1995. Further information
can be found at http://www.w3.org/pub/WWW/MarkUp/ or at
ftp://ds.internic.net/rfc/rfc1866.txt
HTML 3.0
Hypertext Markup Language Specification Version 3.0. The initial
draft specification as published in March 1995. Work on refining
HTML3 is proceeding piecemeal with the new table specification
as one of the pieces. For W3C related work on HTML, see
http://www.w3.org/pub/WWW/MarkUp/.
RFC 1766
"Tags for the Identification of Languages", by H. Alvestrand,
UNINETT, March 1995. This document can be downloaded from
ftp://ds.internic.net/rfc/rfc1766.txt.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Dave Raggett W3C
EMail: dsr@w3.org
The World Wide Web Consortium: http://www.w3.org/
Raggett Experimental [Page 30]
|