Before the creation of the HTML Table model, the only method
available for relative alignment of text or objects was through
the use of the PRE element. While this was
useful in some situations, the effects of PRE are very limited,
and some other solution was definitely necessary to resolve this need.
Current desktop publishing packages provide a high degree of
control over table rendering using other document formats.
Unfortunately, it would be impractical to reproduce this in HTML
given the otherwise simplistic nature of the language, without
making HTML into a bulky rich text format [like RTF or MIF.]
Given this requirement, the table model that has been developed
is still definitely THE most complex formatting
structure in HTML. Its design supports rendering to braille or speech,
as well as exchange of tabular data with databases and spreadsheets.
The model is also designed to work well with style sheets, but does
not require them.
History of HTML Tables
The HTML table model has evolved from studies of existing SGML
table models, the treatment of tables in common word processing
packages, and looking at a wide range of tabular layouts in
magazines, books and other paper-based documents.
After HTML 2.0 (RFC 1866) was forwarded as a proposed standard,
work had already begun on extending the capabilities of HTML.
The result of this was HTML + in late 1993. One of the most
important features of HTML + was its Table model which allowed
tabular representation of data WITHOUT the use of the
preformatted text (PRE) element.
HTML + later developed (after much refinement) into the draft for
HTML 3.0. The 3.0 draft sported Tables capability like its HTML +
predecessor, but improved on its features. Many browsers have since
implemented this 3.0 Table model.
Since creating this HTML 3 Table model, a great deal of refinement has
occurred. The current full Tables specification has risen from
the ashes of the expired HTML 3.0 draft to give the author an
intuitive and intentionally simple design that is sufficient for
most authoring purposes. This makes it practical to create the
HTML codes for tables with simple text editors and reduces the
learning curve when getting started - factors critical to the
success of HTML thus far.
Tables in a Nutshell
The concept of Tables in HTML involves content that is contained
in individual cell structures. These cells can contain other HTML
structures such as headers, lists, paragraphs, forms, multimedia objects,
preformatted text and even nested tables.
The TABLE model is a sort of hybrid element. It exhibits line-breaking
behaviors which are similar to other Block formatting structures (like
lists and headings) and floating ability similar to that of other
replaced elements (like IMG.)
The top level Table container element [TABLE]
controls global properties for the table structure itself, while
the various other elements and attributes for tables organize and
format the contained cell content into row and column structures.
Table capabilities such as in-cell alignment for example,
are allowed in most of the Table elements, from the cell level
[TH, TD] to the
highest grouping elements [COLGROUP,
THEAD, TBODY,
TFOOT, TR.] This
allows for more efficient specification of global properties. In
cases where global properties specified at one level conflicts
with that specified elsewhere, the most specific value wins - cell
properties take precedence over row grouping properties, and
properties within cells take precedence over all of these.
This is the Table Model that most browsers currently support.
The model is from the HTML + and HTML 3.0 Draft specifications which
describes tables in terms of table cells grouped into row-based
[TR] cell layouts. The row structures are the only
grouping mechanism for the Simple Table Model. Organization of content
with greater complexity is accomplished with greater finesse using the
Complex Model.
At the lowest level of a table structure are the table cells which contain
all table content. Table cells are distinguished into header
[TH] and data [TD]
cells. This distinction allows browsers to render header and data cells
distinctly, even in the absence of style sheets. Cells can also span or
merge across 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 (or on the left side if the current language
direction indicates it.)
As can be guessed, it is also possible to create tables with overlapping
cells. In these cases, the rendering of the table is left to the browser.
The Complex model incorporates all the elements of Simple
tables in addition to many new elements that give the author
even more organizational control. The Complex model inherits
certain aspects of the CALS
Table Model, such as the ability to group Table Rows into
THEAD, TBODY
and TFOOT sections, as well as the
ability to specify cell alignment compactly for sets of cells
according to the context. The Complex table model is also fully
backward-compatible with the Simple table model. This allows simple
tables to be expressed simply with extra complexity added only
when needed.
The Complex Table Model offers several rendering advantages over
the Simple Model:
Incremental Display
For large tables or slow network connections, it is desirable to be
able to start displaying the table before all of the data has been
received. To achieve this, the table must explicitly state the number
of columns contained before any of the table content is received [COLS attribute.] Using the COLGROUP and COL
elements the author can also specify relative or absolute sizes for each
column of the table (all cells in a column have the same width.)
Scrolling and Non-Scrolling Table Regions
When rendering to a paged device (i.e. a printer), tables will
often have to be broken across page boundaries. Grouping Table Rows
[TR] in to Header
[THEAD], Body
[TBODY] and Footer
[TFOOT] elements allows the browser 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. Also, If the table has a large number of rows in the
TBODY, a browser may choose to use a scrolling region for its
display of the Table Body sections while keeping the Header and
Footer sections in a static position. [NOTE: The suggestion about repeated table
headers/footers with printed material is a statement originally from
the HTML 4 spec - as of the time of writing, only Mozilla 1.0/Netscape 7.0
does this - maybe this feature will gain wider acceptance in the future.]
THEAD and TFOOT are placed before the TBODY in the markup sequence,
so that browsers can render the header and footer before receiving
all of the Table Body data. Each THEAD, TFOOT and TBODY element must
contain one or more TR elements.
Complex Internal and External Border
Control Rendering
The Simple table model only offers one universal control mechanism
for specifying borders in a table. An author can specify a static border
thickness (or none at all) that applies around all cells in the table. The
Complex model, on the other hand, offers authors the ability to choose
from a set of commonly used classes of border styles to independently
control the outer table border [FRAME
attribute] and inner table cell borders
[RULES attribute.]