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
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.
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.
<!-- Content model entities imported from parent DTD:
%body.content; allows table cells to contain headers, paras,
lists, form elements and even arbitrarily nested tables.
%text; is text characters, including character entities and
character emphasis elements, IMG and anchors
-->
<!ENTITY % attrs
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
lang NAME #IMPLIED -- as per RFC1766 --
dir (ltr|rtl) #IMPLIED -- I18N text direction --">
<!--
The BORDER attribute sets the thickness of the frame around the
table. The default units are screen pixels.
The FRAME attribute specifies which parts of the frame around
the table should be rendered. The values are not the same as
CALS to avoid a name clash with the VALIGN attribute.
The value "border" is included for backwards compatibility with
<TABLE BORDER> which yields frame=border and border=implied
For <TABLE BORDER=1> you get border=1 and frame=implied. In this
case, its appropriate to treat this as frame=border for backwards
compatibility with deployed browsers.
-->
<!ENTITY % Frame "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
<!--
The RULES attribute defines which rules to draw between cells:
If RULES is absent then assume:
"none" if BORDER is absent or BORDER=0 otherwise "all"
-->
<!ENTITY % Rules "(none | groups | rows | cols | all)">
<!-- horizontal placement of table relative to window -->
<!ENTITY % Where "(left|center|right)">
<!-- horizontal alignment attributes for cell contents -->
<!ENTITY % cell.halign
"align (left|center|right|justify|char) #IMPLIED
char CDATA #IMPLIED -- alignment char, e.g. char=':' --
charoff CDATA #IMPLIED -- offset for alignment char --"
>
<!-- vertical alignment attributes for cell contents -->
<!ENTITY % cell.valign
"valign (top|middle|bottom|baseline) #IMPLIED"
>
<!ELEMENT table - - (caption?, (col*|colgroup*), thead?, tfoot?, t
body+)>
<!ELEMENT caption - - (%text;)+>
<!ELEMENT thead - O (tr+)>
<!ELEMENT tfoot - O (tr+)>
<!ELEMENT tbody O O (tr+)>
<!ELEMENT colgroup - O (col*)>
<!ELEMENT col - O EMPTY>
<!ELEMENT tr - O (th|td)+>
<!ELEMENT (th|td) - O %body.content>
<!ATTLIST table -- table element --
%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 --
>
<!-- ALIGN is used here for compatibility with deployed browsers -->
<!ENTITY % Caption "(top|bottom|left|right)">
<!ATTLIST caption -- table caption --
%attrs; -- id, lang, dir and class --
align %Caption; #IMPLIED -- relative to table --
>
<!--
COLGROUP groups a set of COL elements. It allows you to group
several columns together.
-->
<!ATTLIST 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 --
%cell.valign; -- vertical alignment in cells --
>
<!--
COL elements define the alignment properties for cells in a given
column or spanned columns. The WIDTH attribute specifies the
width of the columns, e.g.
width=64 width in screen pixels
width=0.5* relative width of 0.5
-->
<!ATTLIST col -- column groups and 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 --
>
<!--
Use THEAD to duplicate headers when breaking table
across page boundaries, or for static headers when
body sections are rendered in scrolling panel.
Use TFOOT to duplicate footers when breaking table
across page boundaries, or for static footers when
body sections are rendered in scrolling panel.
Use multiple TBODY sections when rules are needed
between groups of table rows.
-->
<!ATTLIST (thead|tbody|tfoot) -- table section --
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
<!ATTLIST tr -- table row --
%attrs; -- id, lang, dir and class --
%cell.halign; -- horizontal alignment in cells --
%cell.valign; -- vertical alignment in cells --
>
<!ATTLIST (th|td) -- header or data cell --
%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 --
>
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
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/.
RFC1766
"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/