| females | 1.7 | 0.002
On a dumb terminal, this would be rendered something like
A test table with merged
/--------------------------------------------------\
| | Average | other | Misc |
| |-------------------| category |--------|
| | height | weight | | |
|-----------------------------------------|--------|
| males | 1.9 | 0.003 | | |
|-----------------------------------------|--------|
| females | 1.7 | 0.002 | | |
\--------------------------------------------------/
Raggett Experimental [Page 3]
RFC 1942 HTML Tables May 1996
Next, a richer example with grouped rows and columns (adapted
"Developing International Software" by Nadine Kano). First here
what the table looks like on paper
CODE-PAGE SUPPORT IN MICROSOFT
========================================================================
Code-Page| Name |ACP OEMCP| Windows Windows
ID | | | NT 3.1 NT 3.51 95
------------------------------------------------------------------------
1200 |Unicode (BMP of ISO 10646) | | X X *
1250 |Windows 3.1 East. Europe | X | X X
1251 |Windows 3.1 Cyrillic | X | X X
1252 |Windows 3.1 US (ANSI) | X | X X
1253 |Windows 3.1 Greek | X | X X
1254 |Windows 3.1 Turkish | X | X X
1255 |Hebrew | X |
1256 |Arabic | X |
1257 |Baltic | X |
1361 |Korean (Johab) | X | **
------------------------------------------------------------------------
437 |MS-DOS United States | X | X X
708 |Arabic (ASMO 708) | X |
709 |Arabic (ASMO 449+, BCON V4)| X |
710 |Arabic (Transparent Arabic)| X |
720 |Arabic (Transparent ASMO) | X |
========================================================================
The markup for this uses COLGROUP elements to group columns and
set default column alignment. TBODY elements are used to group rows
The FRAME and RULES attributes are used to select which borders
render
CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
Code-Page
|
|
|
| Windows
NT 3.1
| Windows
NT 3.51
| Windows
95
Raggett Experimental [Page 4]
RFC 1942 HTML Tables May 1996
| 1200 | Unicode (BMP of ISO 10646) | | | X | X | *
| | 1250 | Windows 3.1 Eastern European | X | | X | X |
| | 1251 | Windows 3.1 Cyrillic | X | | X | X |
| | 1252 | Windows 3.1 US (ANSI) | X | | X | X |
| | 1253 | Windows 3.1 Greek | X | | X | X |
| | 1254 | Windows 3.1 Turkish | X | | X | X |
| | 1255 | Hebrew | X | | | |
| | 1256 | Arabic | X | | | |
| | 1257 | Baltic | X | | | |
| | 1361 | Korean (Johab) | X | | | ** |
| 437 | MS-DOS United States | | X | X | X |
| | 708 | Arabic (ASMO 708) | | X | | |
| | 709 | Arabic (ASMO 449+, BCON V4) | | X | | |
| | 710 | Arabic (Transparent Arabic) | | X | | |
| | 720 | Arabic (Transparent ASMO) | | X | | |
Design
The HTML table model has evolved from studies of existing SGML
models, the treatment of tables in common word processing packages
and looking at a wide range of tabular layout in magazines, books
other paper-based documents. The model was chosen to allow
tables to be expressed simply with extra complexity only when needed
This makes it practical to create the markup for HTML tables
everyday text editors and reduces the learning curve for
started. This feature has been very important to the success of
to date
Increasingly people are using filters from other document formats
direct wysiwyg editors for HTML. It is important that the HTML
model fits well with these routes for authoring HTML. This
how the representation handles cells which span multiple rows
columns, and how alignment and other presentation properties
associated with groups of cells
A major consideration for the HTML table model is that the fonts
window sizes etc. in use with browsers are not under the author'
control. This makes it risky to rely on column widths specified
terms of absolute units such as picas or pixels. Instead, tables
be dynamically sized to match the current window size and fonts
Authors can provide guidance as to the relative widths of columns
but user agents should to ensure that columns are wide enough
render the width of the largest single element of the cell's content
If the author's specification must be overridden, it is
that the relative widths of individual columns are not
drastically
Raggett Experimental [Page 5]
RFC 1942 HTML Tables May 1996
For large tables or slow network connections, it is desirable to
able to start displaying the table before all of the data has
received. The default window width for most user agents shows
80 characters, and the graphics for many HTML pages are designed
these defaults in mind. Authors can provide a hint to user agents
activate incremental display of table contents. This feature
the author to specify the number of columns, and includes
for control of table width and the widths of different columns
relative or absolute terms
For incremental display, the browser needs the number of columns
their widths. The default width of the table is the current
size (width="100%"). This can be altered by including a
attribute in the TABLE start tag. By default all columns have
same width, but you can specify column widths with one or more
elements before the table data starts
The remaining issue is the number of columns. Some people
suggested waiting until the first row of the table has been received
but this could take a long time if the cells have a lot of content
On the whole it makes more sense, when incremental display
desired, to get authors to explicitly specify the number of
in the TABLE start tag
Authors still need a way of informing the browser whether to
incremental display or to automatically size the table to match
cell contents. For the two pass auto sizing mode, the number
columns is determined by the first pass, while for the
mode, the number of columns needs to be stated up front. So it
to that COLS=_nn_ would be better for this purpose than a
attribute such as LAYOUT=FIXED or LAYOUT=AUTO
It is generally held useful to consider documents from
perspectives: Structural idioms such as headers, paragraphs, lists
tables, and figures; and rendering idioms such as margins, leading
font names and sizes. The wisdom of past experience encourages us
separate the structural information in documents from
information. Mixing them together ends up causing increased cost
ownership for maintaining documents, and reduced portability
applications and media
For tables, the alignment of text within table cells, and the
between cells are, from the purist's point of view,
information. In practice, though, it is useful to group these
the structural information, as these features are highly
from one application to the next. The HTML table model leaves
rendering information to associated style sheets. The model
designed to take advantage of such style sheets but not to
Raggett Experimental [Page 6]
RFC 1942 HTML Tables May 1996
them
This specification provides a superset of the simpler model
in earlier work on HTML+. Tables are considered as being formed
an optional caption together with a sequence of rows, which in
consist of a sequence of table cells. The model
differentiates header and data cells, and allows cells to
multiple rows and columns
Following the CALS table model, this specification allows table
to be grouped into head and body and foot sections. This
the representation of rendering information and can be used to
table head and foot rows when breaking tables across page boundaries
or to provide fixed headers above a scrollable body panel. In
markup, the foot section is placed before the body sections. This
an optimization shared with CALS for dealing with very long tables
It allows the foot to be rendered without having to wait for
entire table to be processed
For the visually impaired, HTML offers the hope of setting to
the damage caused by the adoption of windows based graphical
interfaces. The HTML table model includes attributes for
each cell, to support high quality text to speech conversion.
same attributes can also be used to support automated import
export of table data to databases or spreadsheets
Current desktop publishing packages provide very rich control
the rendering of tables, and it would be impractical to
this in HTML, without making HTML into a bulky rich text format
RTF or MIF. This specification does, however, offer authors
ability to choose from a set of commonly used classes of
styles. The FRAME attribute controls the appearence of the
frame around the table while the RULES attribute determines
choice of rulings within the table
During the development of this specification, a number of
were investigated for specifying the ruling patterns for tables.
issue concerns the kinds of statements that can be made.
support for edge subtraction as well as edge addition leads
relatively complex algorithms. For instance work on allowing the
set of table elements to include the FRAME and RULES attributes
to an algorithm involving some 24 steps to determine whether
particular edge of a cell should be ruled or not. Even
additional complexity doesn't provide enough rendering control
meet the full range of needs for tables. The current
deliberately sticks to a simple intuitive model, sufficient for
purposes. Further experimental work is needed before a more
approach is standardized
Raggett Experimental [Page 7]
RFC 1942 HTML Tables May 1996
A walk through the table
The table document type definition provides the formal definition
the allowed syntax for html tables. The following is an
listing of the DTD. The complete listing appears at the end of
document
Note that the TABLE element is a block-like element rather
character-level element. As such it is a peer of other HTML block
like elements such as paragraphs, lists and headers
Common
The following attributes occur in several of the elements and
defined here for brevity. In general, all attribute names and
in this specification are case insensitive, except where
otherwise. The ID, CLASS and attributes are required for use
style sheets, while LANG and DIR are needed for internationalization
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
lang NAME #IMPLIED -- as per RFC 1766 --
dir (ltr|rtl) #IMPLIED -- I18N text direction --">
Used to define a document-wide identifier. This can be used
naming positions within documents as the destination of
hypertext link. It may also be used by style sheets
rendering an element in a unique style. An ID attribute value
an SGML NAME token. NAME tokens are formed by an initial
followed by letters, digits, "-" and "." characters. The
are restricted to A-Z and a-z
A space separated list of SGML NAME tokens. CLASS names
that the element belongs to the corresponding named classes.
allows authors to distinguish different roles played by the
tag. The classes may be used by style sheets to
different renderings as appropriate to these roles
A LANG attribute identifies the natural language used by
content of the associated element.The syntax and registry
language values are defined by RFC 1766. In summary the
is given as a primary tag followed by zero or more subtags
separated by "-". White space is not allowed and all tags
case insensitive. The name space of tags is administered
Raggett Experimental [Page 8]
RFC 1942 HTML Tables May 1996
IANA. The two letter primary tag is an ISO 639
abbreviation, while the initial subtag is a two letter ISO 3166
country code. Example values for LANG include
en, en-US, en-uk, i-cherokee, x-pig-latin
Human writing systems are grouped into scripts, which
amongst other things, the direction the characters are written
Elements of the Latin script are nominally left to right,
those of the Arabic script are nominally right to left.
characters have what is called strong directionality.
characters can be directionally neutral (spaces) or
(punctuation).
The DIR attribute specifies an encapsulation boundary
governs the interpretation of neutral and weakly
characters. It does not override the directionality of
directional characters. The DIR attribute value is one of
for left to right, or RTL for right to left, e.g. DIR=RTL
When applied to TABLE, it indicates the geometric layout of
(i.e. row 1 is on right if DIR=RTL, but on the left if DIR=LTR
and it indicates a default base directionality for any text
the table's content if no other DIR attribute applies to
text
Horizontal and Vertical Alignment
The alignment of cell contents can be specified on a cell by
basis, or inherited from enclosing elements, such as the row,
or the table element itself
This specifies the horizontal alignment of cell contents
"align (left|center|right|justify|char) #
char CDATA #IMPLIED -- alignment char, e.g. char=':' --
charoff CDATA #IMPLIED -- offset for alignment char --"
>
The attribute value should be one of LEFT, CENTER, RIGHT
JUSTIFY and CHAR. User agents may treat JUSTIFY as
alignment if they lack support for text justification
ALIGN=CHAR is used for aligning cell contents on a
character
Raggett Experimental [Page 9]
RFC 1942 HTML Tables May 1996
For cells spanning multiple rows or columns, where the
property is inherited from the row or column, the initial
and column for the cell determines the appropriate
property to use
Note that an alignment attribute on elements within the cell
e.g. on a P element, overrides the normal alignment value
the cell
This is used to specify an alignment character for use
align=char, e.g. char=":". The default character is the
point for the current language, as set by the LANG attribute
The CHAR attribute value is case sensitive
Specifies the offset to the first occurrence of the
character on each line. If a line doesn't include the
character, it should be horizontally shifted to end at
alignment position. The resolved direction of the cell,
determined by the inheritance of the DIR attribute, is used
set whether the offset is from the left or right margin of
cell. For Latin scripts, the offset will be from the
margin, while for Arabic scripts, it will be from the
margin. In addition to standard units, the "%" sign may be
to indicate that the value specifies the alignment position as
percentage offset of the current cell, e.g. CHAROFF="30%"
indicates the alignment character should be positioned 30%
through the cell
When using the two pass layout algorithm, the default
position in the absence of an explicit or inherited
attribute can be determined by choosing the position that
center lines for which the width before and after the
character are at the maximum values for any of the lines in
column for which ALIGN=CHAR. For incremental table layout
suggested default is CHAROFF="50%". If several cells
different rows for the same column use character alignment,
by default, all such cells should line up, regardless of
character is used for alignment. Rules for handling objects
large for column apply when the explicit or implied
results in a situation where the data exceeds the assigned
of the column
Defines whether the cell contents are aligned with the top
middle or bottom of the cell
Raggett Experimental [Page 10]
RFC 1942 HTML Tables May 1996
"valign (top|middle|bottom|baseline) #IMPLIED
>
If present, the value of the attribute should be one of: TOP
MIDDLE, BOTTOM or BASELINE. All cells in the same row
valign=baseline should be vertically positioned so that
first text line in each such cell occur on a common baseline
This constraint does not apply to subsequent text lines in
cells
Inheritance
Alignment properties can be included with most of the table elements
COL, THEAD, TBODY, TFOOT, TR, TH and TD. When rendering cells
horizontal alignment is determined by columns in preference to rows
while for vertical alignment, the rows are more important than
columns. The following table gives the detailed precedence order
each attribute, where X > Y denotes that X takes precedence over Y
ALIGN, CHAR and CHAROFF
cells > columns > column groups > rows > row groups >
VALIGN, LANG, and DIR
cells > rows > row groups > columns > column groups > table >
Where cells are defined by TH and TD elements; rows by TR elements
row groups by THEAD, TBODY and TFOOT elements, columns by
elements; and column groups by COLGROUP and COL elements. Note
there is no inheritance mechanism for the CLASS attribute
Properties defined on cells take precedence over
properties, but are in turn over-ridden by alignment properties
elements within cells. In the absence of an ALIGN attribute along
inheritance path, the recommended default alignment for table
contents is ALIGN=LEFT for table data and ALIGN=CENTER for
headers. The recommended default for vertical alignment
VALIGN=MIDDLE. These defaults are chosen to match the behaviour
the widely deployed Netscape implementation
Standard Units for
Several attributes specify widths as a number followed by an
suffix. The units for widths are specified by the suffix: pt
points, pi denotes picas, in denotes inches, cm denotes centimeters
Raggett Experimental [Page 11]
RFC 1942 HTML Tables May 1996
mm denotes millimeters, em denotes em units (equal to the height
the default font), and px denotes screen pixels. The default
are screen pixels (chosen for backwards compatibility). The number
an integer value or a real valued number such as "2.5". Exponents,
in "1.2e2", are not allowed. White space is not allowed between
number and the suffix
The above set of suffices is augmented for certain elements: "%"
used for the WIDTH attribute for the TABLE element. It indicates
the attribute specifies the percentage width of the space between
current left and right margins, e.g. width="50%". For the
element, "*" is used with the WIDTH attribute to specify
column widths, e.g. width="3*", using the same representation as
CALS table model
The TABLE
%attrs; -- id, lang, dir and class --
align %Where; #IMPLIED -- table position relative to --
-- window --
width CDATA #IMPLIED -- table width relative to window --
cols NUMBER #IMPLIED -- used for immediate display mode --
border CDATA #IMPLIED -- controls frame width around --
-- table --
frame %Frame; #IMPLIED -- which parts of table frame to --
-- include --
rules %Rules; #IMPLIED -- controls rules between cells --
cellspacing CDATA #IMPLIED -- spacing between cells --
cellpadding CDATA #IMPLIED -- spacing within cells --
>
The TABLE element requires both start and end tags. Table
start with an optional CAPTION element, optionally followed by
one or more COL elements, or one or more COLGROUP elements, then
optional THEAD, an optional TFOOT, and finally one or more
elements
ID, CLASS, LANG and
See earlier description of common attributes
Defines the horizontal position of the table relative to
current left and right margins. ALIGN=CENTER centers the
Raggett Experimental [Page 12]
RFC 1942 HTML Tables May 1996
midway between the left and right margins. ALIGN=LEFT
the table at the left margin, while ALIGN=RIGHT positions
table at the right margin. User agents may flow text around
right handside of the table for ALIGN=LEFT, or the left
for ALIGN=RIGHT
Note you can use
after the table element if
want to avoid text flowing along side the table when you
specified ALIGN=LEFT, or
for a right
table. To prevent a right aligned table flowing around
else, use
before the table etc. Greater
over textflow is possible using style sheets
Specifies the desired width of the table. In addition to
standard units, the "%" sign may used to indicate that the
specifies the percentage width of the space between the
left and right margins, e.g. width="50%". In the absence of
attribute, the table width can be determined by the
algorithm given later on
It is recommended that the table width be increased beyond
value indicated by the WIDTH attribute as needed to avoid
overflow of cell contents. Such increases should try to
drastic changes to relative column widths specified by
author. To avoid the need for excessive horizontal scrolling,
when such scrolling is impractical or undesired, it may
appropriate to split words across lines
Specifies the number of columns for the table. If present
user agent may render the table dynamically as data is
from the network without waiting for the complete table to
received. If the WIDTH attribute is missing, a default of "100%"
may be assumed for this purpose. If the COLS attribute
absent, a prepass through the table's contents is needed
determine the number of columns together with suitable
for the widths of each column
Specifies the width of the border framing the table,
standard units
Specifies which sides of the frame to render
"(void|above|below|hsides|lhs|rhs|vsides|box|border)">
Raggett Experimental [Page 13]
RFC 1942 HTML Tables May 1996
Don't render any sides of the frame
The top side of the
The bottom side of the
The top and bottom sides of the
The left hand side of the
The right hand side of the
The left and right sides of the
All four sides of the
All four sides of the
The value "Border" is included for backwards compatibility
deployed browsers. If a document includes
user agent will see FRAME=BORDER and BORDER=_implied_. If
document includes then the user agent
treat this as FRAME=BORDER except if _n=0_ for which FRAME=
is appropriate
Note: it would have been preferable to choose values for
consistent with the RULES attribute and the values used
alignment. For instance: none, top, bottom, topbot, left, right
leftright, all. Unfortunately, SGML requires
attribute values to be unique for each element, independent
the attribute name. This causes immediate problems for "none",
"left", "right" and "all". The values for FRAME have been
to avoid clashes with the RULES, ALIGN and VALIGN attributes
This provides a measure of future proofing, as it is
that that the FRAME and RULES attributes will be added to
table elements in future revisions to this specification.
alternative would be to make FRAME a CDATA attribute.
consensus of the HTML-WG was that the benefits of being able
use SGML validation tools to check attributes based
Raggett Experimental [Page 14]
RFC 1942 HTML Tables May 1996
enumerated values outweighs the need for consistent names
Specifies where to draw rules within the table interior
Suppresses internal rulings
The THEAD, TFOOT and TBODY elements divide the table
groups of rows, while COLGROUP elements divide the
into groups of columns. This choice places a horizontal
between each row group and a vertical rule between
column group. Note that every table has at least one row
one column group
As RULES=GROUPS plus horizontal rules between all rows.
agents may choose to use a heavier rule between groups
rows and columns for emphasis
As RULES=GROUPS plus vertical rules between all columns
User agents may choose to use a heavier rule between
of rows and columns for emphasis
Place rules between all rows and all columns. User
may choose to use a heavier rule between groups of rows
columns for emphasis
If a document includes or
the default for the table element is RULES=ALL, except if _n=0_
for which RULES=NONE is appropriate
This attribute is intended for backwards compatibility
deployed user agents. It specifies the space between the
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
This attribute is intended for backwards compatibility
deployed user agents. It specifies the amount of space
the border of the cell and its contents both above/below,
Raggett Experimental [Page 15]
RFC 1942 HTML Tables May 1996
left//right. See standard units. Greater control will
possible using style sheet languages
If a fixed width is set for the table or column, the CELLSPACING
CELLPADDING may demand more space than assigned. Current practice
for the latter to take precedence over WIDTH attributes when
conflict occurs, although this isn't required by this specification
Table
%attrs; -- id, lang, dir and class --
align %Caption; #IMPLIED -- relative to table --
>
The optional CAPTION element is used to provide a caption for
table. Both start and end tags are required
ID, CLASS, LANG and
See earlier description of common attributes
This may be used to control the placement of captions
to the table. When present, the ALIGN attribute should have
of the values: TOP, BOTTOM, LEFT and RIGHT. It is
that the caption is made to fit within the width or height
the table as appropriate. The default position of the caption
deliberately unspecified
Note the ALIGN attribute is overused in HTML, but is
here for compatibility with currently deployed browsers
The COLGROUP
%attrs; -- id, lang, dir and class --
span NUMBER 1 -- default number of columns in --
-- group --
width CDATA #IMPLIED -- default width for enclosed --
-- COLs --
%cell.halign; -- horizontal alignment in --
-- cells --
Raggett Experimental [Page 16]
RFC 1942 HTML Tables May 1996
%cell.valign; -- vertical alignment in cells --
>
The COLGROUP element acts as a container for a group of columns,
allows you to set default properties for these columns. In
absence of a COLGROUP element, all columns in the table are
to belong to a single column group. Each COLGROUP element
contain zero or more COL elements. COLGROUP requires a start tag
but the end tag may be omitted. This is useful when defining
sequence of COLGROUP elements, e.g
...
COLGROUP elements can be used with the following attributes
ID, CLASS, LANG and
See earlier description of common attributes
A positive integer value that specifies a default for how
columns are in this group. This attribute should be ignored
the COLGROUP element contains one or more COL elements.
provides a convenient way of grouping columns without the
to supply COL elements
Specifies a default width for each of the grouped columns,
standard units. In addition, the "*" suffix denotes
widths, e.g
width=64 width in screen
width=0.5* a relative width of 0.5
Relative widths act as constraints on the relative widths
different columns. If a COLGROUP element specifies a
width of zero, all of the columns in the group should be set
their minimum widths, unless they are associated with a
element with an overriding WIDTH attribute. When widths
Raggett Experimental [Page 17]
RFC 1942 HTML Tables May 1996
given in absolute units, the user agent can use these
constrain the width of the table. The "*" suffix is used
simplify importing tables from the CALS representation
ALIGN, CHAR, CHAROFF and
Specify values for horizontal and vertical alignment
table cells. See inheritance order of alignment properties
The COL
-- properties --
%attrs; -- id, lang, dir and class --
span NUMBER 1 -- number of columns spanned --
-- by group --
width CDATA #IMPLIED -- column width specification --
%cell.halign; -- horizontal alignment in --
-- cells --
%cell.valign; -- vertical alignment in cells --
>
This optional element is used to specify column based defaults
table properties. It is an empty element, and as such has
content, and shouldn't be given an end tag. Several COL elements
be given in succession. COL attributes override those of the
COLGROUP element
ID, CLASS, LANG and
See earlier description of common attributes
A positive integer value that specifies how many columns
element applies to, defaulting to one. In the absence of
attributes the first COL element applies to the first column
the second COL element to the second column and so on. If
second COL element had SPAN=2, it would apply to the second
third column. The next COL element would then apply to
fourth column and so on. SPAN=0 has a special significance
implies that the COL element spans all columns from the
column up to and including the last column. Note that a COL
does not define a group. It is merely a way to share
definitions
Raggett Experimental [Page 18]
RFC 1942 HTML Tables May 1996
Specifies the width of the columns, see standard units. If
element spans several columns then the WIDTH attribute
the width for each of the individual columns - not the width
the span. In addition, the "*" suffix denotes relative widths
e.g
width=64 width in screen
width=0.5* a relative width of 0.5
Relative widths act as constraints on the relative widths
different columns. If a COL element specifies a relative
of zero, the column should always be set to its minimum width
When widths are given in absolute units, the user agent can
these to constrain the width of the table. The "*" suffix
used to simplify importing tables from the CALS representation
ALIGN, CHAR, CHAROFF and
Specify values for horizontal and vertical alignment
table cells. See inheritance order of alignment properties
Table Head, Foot and Body
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in --
-- cells --
%cell.valign; -- vertical alignment in cells --
>
Tables may be divided up into head and body sections. The THEAD
TFOOT elements are optional, but one or more TBODY elements
always required. If the table only consists of a TBODY section,
TBODY start and end tags may be omitted, as the parser can
them. If a THEAD element is present, the THEAD start tag
required, but the end tag can be omitted, provided a TFOOT or
start tag follows. The same applies to TFOOT
Note: This definition provides compatibility with tables
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
controlling rendering. If the table has a large number of rows
the body, user agents may choose to use a scrolling region for
table body sections. When rendering to a paged device, tables
often have to be broken across page boundaries. The THEAD, TFOOT
TBODY elements allow the user agent to repeat the table foot at
bottom of the current page, and then the table head at the top
the new page before continuing on with the table body
TFOOT is placed before the TBODY in the markup sequence, so
browsers can render the foot before receiving all of the table data
This is useful when very long tables are rendered with
body sections, or for paged output, involving breaking the
over many pages
Each THEAD, TFOOT and TBODY element must contain one or more
elements
ID, CLASS, LANG and
See earlier description of common attributes
ALIGN, CHAR, CHAROFF and
Specify values for horizontal and vertical alignment
table cells. See inheritance order of alignment properties
Table Row (TR)
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in --
-- cells --
%cell.valign; -- vertical alignment in cells --
>
The TR or table row element acts as a container for a row of
cells. The end tag may be omitted
ID, CLASS, LANG and
See earlier description of common attributes
ALIGN, CHAR, CHAROFF and
Specify values for horizontal and vertical alignment
table cells. See inheritance order of alignment properties
Raggett Experimental [Page 20]
RFC 1942 HTML Tables May 1996
Table Cells: TH and
%attrs; -- id, lang, dir and class --
axis CDATA #IMPLIED -- defaults to cell content --
axes CDATA #IMPLIED -- list of axis names --
nowrap (nowrap) #IMPLIED -- suppress word wrap --
rowspan NUMBER 1 -- number of rows spanned by --
-- cell --
colspan NUMBER 1 -- number of cols spanned by --
-- cell --
%cell.halign; -- horizontal alignment in --
-- cells --
%cell.valign; -- vertical alignment in cells --
>
TH elements are used to represent header cells, while TD
are used to represent data cells. This allows user agents to
header and data cells distinctly, even in the absence of
sheets
Cells can span multiple rows and columns, and may be empty.
spanning rows contribute to the column count on each of the
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
implied by cells spanning rows beyond this should be ignored
If the column count for the table is greater than the number
cells for a given row (after including cells for spanned rows),
missing cells are treated as occurring on the right hand side of
table and rendered as empty cells. If the language context
a right to left writing order, then the missing cells should
placed on the left hand side
It is possible to create tables with overlapping cells,
instance
| 1 | 2 | 3
| 4
| | 5 | 6
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
concise labels for cells. When rendering to speech, these
may be used to provide abbreviated names for the headers relevant
each cell. Another application is when you want to be able to
process table contents to enter them into a database.
attributes are then used to give database field names. The table'
class attribute should be used to let the software recognize
tables can be treated in this way
ID, CLASS, LANG and
See earlier description of common attributes
This defines an abbreviated name for a header cell, e.g.
can be used when rendering to speech. It defaults to the cell'
content
This is a comma separated list of axis names which
identify the row and column headers that pertain to this cell
It is used for example when rendering to speech to identify
cell's position in the table. If missing the user agent can
to follow up columns and left along rows (right for
languages) to find the corresponding header cells
NOWRAP, e.g. |
The presence of this attribute disables automatic wrapping
text lines for this cell. If used uncautiously, it may result
excessively wide cells. This attribute is defined for
compatibility with deployed user agents. Greater control
possible with associated style sheet languages (for example
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
spans. The default ROWSPAN is 1. ROWSPAN=0 has a
significance and implies that the cell spans all rows from
current row up to the last row of the table
COLSPAN, e.g. |
A positive integer value that defines how may columns this
spans. The default COLSPAN is 1. COLSPAN=0 has a
significance and implies that the cell spans all columns
the current column up to the last column of the table
ALIGN, CHAR, CHAROFF and
Specify values for horizontal and vertical alignment
table cells. See inheritance order of alignment properties
Note: It is recommended that implementors provide support for
Netscape 1.1 WIDTH attribute for TH and TD, although this isn't
of the current specification. Document authors are advised to
the width attribute for the COL element instead
Recommended Layout
If the COLS attribute on the TABLE element specifies the number
columns, then the table may be rendered using a fixed layout
otherwise the autolayout algorithm described below should be used
Fixed Layout
For this algorithm, it is assumed that the number of columns
known. The column widths by default should be set to the same size
Authors may override this by specifying relative or absolute
widths, using the COLGROUP or COL elements. The default table
is the space between the current left and right margins, but may
overridden by the WIDTH attribute on the TABLE element, or
from absolute column widths. To deal with mixtures of absolute
relative column widths, the first step is to allocate space from
table width to columns with absolute widths. After this, the
remaining is divided up between the columns with relative widths
The table syntax alone is insufficient to guarantee the
of attribute values. For instance, the number of columns specified
the COLS attribute may be inconsistent with the number of
implied by the COL elements. This in turn, may be inconsistent
the number of columns implied by the table cells. A further
occurs when the columns are too narrow to avoid overflow of
contents. The width of the table as specified by the TABLE element
COL elements may result in overflow of cell contents. It
Raggett Experimental [Page 23]
RFC 1942 HTML Tables May 1996
recommended that user agents attempt to recover gracefully from
situations, e.g. by hyphenating words and resorting to
words if hyphenation points are unknown
In the event that an indivisible element causes cell overflow,
user agent may consider adjusting column widths and re-rendering
table. In the worst case clipping may be considered if column
adjustments and/or scrollable cell content are not feasible. In
case if cell content is split or clipped this should be indicated
the user in an appropriate manner
Autolayout
If the COLS attribute is missing from the table start tag, then
user agent should use the following autolayout algorithm. It uses
passes through the table data and scales linearly with the size
the table
In the first pass, line wrapping is disabled, and the user
keeps track of the minimum and maximum width of each cell.
maximum width is given by the widest line. As line wrap has
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
words, if you were to format the cell's content in a window of
own, determine the minimum width you could make the window before
cell begins to overflow. Allowing user agents to split words
minimize the need for horizontal scrolling or in the worst
clipping of cell contents
This process also applies to any nested tables occuring in
content. The minimum and maximum widths for cells in nested
are used to determine the minimum and maximum widths for these
and hence for the parent table cell itself. The algorithm is
with aggregate cell content, and broadly speaking independent of
depth of nesting
To cope with character alignment of cell contents, the
keeps three running min/max totals for each column: Left of
char, right of align char and un-aligned. The minimum width for
column is then: max(min_left + min_right, min_non-aligned).
The minimum and maximum cell widths are then used to determine
corresponding minimum and maximum widths for the columns. These
turn, are used to find the minimum and maximum width for the table
Note that cells can contain nested tables, but this doesn'
complicate the code significantly. The next step is to assign
widths according to the available space (i.e. the space between
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
Arena, is to evenly apportion the min/max widths to each of
constituent columns. A slightly more complex approach is to use
min/max widths of unspanned cells to weight how spanned widths
apportioned. Experimental study suggests a blend of the
approaches will give good results for a wide range of tables
The table borders and intercell margins need to be included
assigning column widths. There are three cases
1. The minimum table width is equal to or wider than the
space. In this case, assign the minimum widths and allow
user to scroll horizontally. For conversion to braille, it
be necessary to replace the cells by references to
containing their full content. By convention these appear
the table
2. The maximum table width fits within the available space. In
case, set the columns to their maximum widths
3. The maximum width of the table is greater than the
space, but the minimum table width is smaller. In this case
find the difference between the available space and the
table width, lets call it W. Lets also call D the
between maximum and minimum width of the table
For each column, let d be the difference between maximum
minimum width of that column. Now set the column's width to
minimum width plus d times W over D. This makes columns
large differences between minimum and maximum widths wider
columns with smaller differences
This assignment step is then repeated for nested tables using
minimum and maximum widths derived for all such tables in the
pass. In this case, the width of the parent (i.e. enclosing)
cell plays the role of the current window size in the
description. This process is repeated recursively for all
tables. The topmost table is then rendered using the assigned widths
Nested tables are subsequently rendered as part of the parent table'
cell contents
If the table width is specified with the WIDTH attribute, the
agent attempts to set column widths to match. The WIDTH attribute
not binding if this results in columns having less than their
(i.e. indivisible) widths
Raggett Experimental [Page 25]
RFC 1942 HTML Tables May 1996
If relative widths are specified with the COL element, the
is modified to increase column widths over the minimum width to
the relative width constraints. The COL elements should be taken
hints only, so columns shouldn't be set to less than their
width. Similarly, columns shouldn't be made so wide that the
stretches well beyond the extent of the window. If a COL
specifies a relative width of zero, the column should always be
to its minimum width
HTML Table
The DTD or document type definition provides the formal definition
the allowed syntax for HTML tables
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
lang NAME #IMPLIED -- as per RFC 1766 --
dir (ltr|rtl) #IMPLIED -- I18N text direction --">
Raggett Experimental [Page 26]
RFC 1942 HTML Tables May 1996
"align (left|center|right|justify|char) #
char CDATA #IMPLIED -- alignment char, e.g. char=':' --
charoff CDATA #IMPLIED -- offset for alignment char --"
>
"valign (top|middle|bottom|baseline) #IMPLIED
>
body+)>
%attrs; -- id, lang, dir and class --
align %Where; #IMPLIED -- table position relative to --
-- window --
width CDATA #IMPLIED -- table width relative to window --
cols NUMBER #IMPLIED -- used for immediate display mode --
border CDATA #IMPLIED -- controls frame width around --
-- table --
frame %Frame; #IMPLIED -- which parts of table frame to --
-- include --
rules %Rules; #IMPLIED -- rulings between rows and cols --
cellspacing CDATA #IMPLIED -- spacing between cells --
cellpadding CDATA #IMPLIED -- spacing within cells --
Raggett Experimental [Page 27]
RFC 1942 HTML Tables May 1996
>
%attrs; -- id, lang, dir and class --
align %Caption; #IMPLIED -- relative to table --
>
%attrs; -- id, lang, dir and class --
span NUMBER 1 -- default number of columns in --
-- group --
width CDATA #IMPLIED -- default width for enclosed COLs --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
%attrs; -- id, lang, dir and class --
span NUMBER 1 -- number of columns spanned by --
-- group --
width CDATA #IMPLIED -- column width specification --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
%attrs; -- id, lang, dir and class --
axis CDATA #IMPLIED -- defaults to cell content --
axes CDATA #IMPLIED -- list of axis names --
nowrap (nowrap) #IMPLIED -- suppress word wrap --
rowspan NUMBER 1 -- number of rows spanned by cell --
colspan NUMBER 1 -- number of cols spanned by cell --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
W3C's HTML3 browser, see http://www.w3.org/pub/WWW/Arena/.
Arena was originally created as a proof of concept demo
ideas in the HTML+ specification that preceded HTML3.
browser is now being re-implemented to provide a
implementation of HTML3 along with support for style sheets
client-side scripting
Continuous Acquisition and Life-Cycle Support (
Computer-aided Acquisition and Logistics Support) (CALS) is
Department of Defense (DoD) strategy for achieving
creation, exchange, and use of digital data for weapon
and equipment. More information can be found from the US
CALS home page at http://navysgml.dt.navy.mil/cals.
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
can be found at http://www.w3.org/pub/WWW/MarkUp/ or
ftp://ds.internic.net/rfc/rfc1866.
HTML 3.0
Hypertext Markup Language Specification Version 3.0. The
draft specification as published in March 1995. Work on
HTML3 is proceeding piecemeal with the new table
as one of the pieces. For W3C related work on HTML,
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
ftp://ds.internic.net/rfc/rfc1766.txt
Security
Security issues are not discussed in this memo
Author's
Dave Raggett W3
EMail: dsr@w3.
The World Wide Web Consortium: http://www.w3.org
Raggett Experimental [Page 30]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
| | | | |
|---|
