notes.html

学习HTML的书籍

these defaults in mind. By specifying the number of columns, and
including provision for control of table width and the widths of
different columns, authors can give hints to user agents that allow
the incremental display of table contents.

<p>For incremental display, the browser needs the number of columns
and their widths. The default width of the table is the current window
size (<tt>width="100%"</tt>). This can be altered by setting the <a href="../struct/tables.html#adef-width-TABLE"><samp
class="ainst">width-TABLE</samp></a> attribute of the <a href="../struct/tables.html#edef-TABLE"><samp
class="einst">TABLE</samp></a> element. By default, all columns have the
same width, but you can specify column widths with one or more <a href="../struct/tables.html#edef-COL"><samp
class="einst">COL</samp></a> elements before the table data starts.

<p>The remaining issue is the number of columns. Some people have
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 is desired, to
get authors to explicitly specify the number of columns in the <a href="../struct/tables.html#edef-TABLE"><samp
class="einst">TABLE</samp></a> element.

<p>Authors still need a way of telling user agents whether to use
incremental display or to size the table automatically to fit the
cell contents. In the two pass auto-sizing mode, the number of
columns is determined by the first pass. In the incremental
mode, the number of columns must be stated up front. It makes more
	sense to set the <a href="../struct/tables.html#adef-cols-TABLE"><samp class="ainst-TABLE">cols</samp></a> attribute to
the number of columns rather than using some "layout" attribute (e.g.,
	layout="fixed" or layout="auto").

<h4>Structure and presentation<a name="h-13.2.2.1.3">&nbsp;</a></h4>
<p>HTML distinguishes structural markup such as paragraphs and
quotations from rendering idioms such as margins, fonts, colors,
etc. How does this distinction affect tables?  From the purist's point
of view, the alignment of text within table cells and the borders
between cells is a rendering issue, not one of structure.  In practice,
though, it is useful to group these with the structural information,
as these features are highly portable from one application to the
next. The HTML table model leaves most rendering information to
associated style sheets. The model presented in this specification is
designed to take advantage of such style sheets but not to require
them.

<p>Current desktop publishing packages provide very rich control over
the rendering of tables, and it would be impractical to reproduce this
in HTML, without making HTML into a bulky rich text format like RTF or
MIF.  This specification does, however, offer authors the ability to
choose from a set of commonly used classes of border styles. The <a href="../struct/tables.html#adef-frame"><samp
class="ainst-TABLE">frame</samp></a> attribute controls the appearence of the
border frame around the table while the <a href="../struct/tables.html#adef-rules"><samp
class="ainst-TABLE">rules</samp></a> attribute determines the choice of rulings
within the table. A finer level of control will be supported via
rendering annotations. The <a href="../present/styles.html#adef-style"><samp class="ainst-TABLE">style</samp></a> attribute
can be used for specifying rendering information for individual
elements. Further rendering information can be given with the <a href="../present/styles.html#edef-STYLE"><samp
class="einst">STYLE</samp></a> element in the document head or via linked
style sheets.

<p>During the development of this specification, a number of avenues
were investigated for specifying the ruling patterns for tables. One
issue concerns the kinds of statements that can be made. Including
support for edge subtraction as well as edge addition leads to
relatively complex algorithms.  For instance, work on allowing the
full set of table elements to include the <a href="../struct/tables.html#adef-frame"><samp
class="ainst-TABLE">frame</samp></a> and <a href="../struct/tables.html#adef-rules"><samp class="ainst-TABLE">rules</samp></a>
attributes led to an algorithm involving some 24 steps to determine
whether a particular edge of a cell should be ruled or not. Even this
additional complexity doesn't provide enough rendering control to meet
the full range of needs for tables. The current specification
deliberately sticks to a simple intuitive model, sufficient for most
purposes.  Further experimental work is needed before a more complex
approach is standardized.


<h4>Row and column groups<a name="h-13.2.2.1.4">&nbsp;</a></h4>
<p>This specification provides a superset of the simpler model presented
in earlier work on HTML+. Tables are considered as being formed from an
optional caption together with a sequence of rows, which in turn consist of
a sequence of table cells. The model further differentiates header and data
cells, and allows cells to span multiple rows and columns.

<p>Following the CALS table model (see <a rel="biblioentry"
href="../references.html#ref-CALS">[CALS]</a>), this specification
allows table rows to be grouped into head and body and foot
sections. This simplifies the representation of rendering information
and can be used to repeat table head and foot rows when breaking
tables across page boundaries, or to provide fixed headers above a
scrollable body panel. In the markup, the foot section is placed
before the body sections. This is an optimization shared with CALS for
dealing with very long tables. It allows the foot to be rendered
without having to wait for the entire table to be processed.

<h4>Accessibility<a name="h-13.2.2.1.5">&nbsp;</a></h4>

<p>For the visually impaired, HTML offers the hope of setting to
rights the damage caused by the adoption of windows based graphical
user interfaces. The HTML table model includes attributes for labeling
each cell, to support high quality text to speech conversion. The same
attributes can also be used to support automated import and export of
table data to databases or spreadsheets.


<h3>Recommended Layout Algorithms<a name="h-13.2.2.2">&nbsp;</a></h3>
<p>If the <a href="../struct/tables.html#adef-cols-TABLE"><samp class="ainst-TABLE">cols</samp></a> attribute on the <a href="../struct/tables.html#edef-TABLE"><samp
class="einst">TABLE</samp></a> 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.

<P>If the <samp>width</samp> attribute is not specified, visual user
agents should assume a default value of <tt>100%</tt> for formatting.

<P>We recommended that user agents increase table widths beyond the
value specified by <samp>width</samp> in cases when cell contents
would otherwise overflow. User agents that override the specified
width should do so within reason. User agents may elect to split words
across lines to avoid the need for excessive horizontal scrolling or
when such scrolling is impractical or undesired.

<h4>Fixed Layout Algorithm<a name="h-13.2.2.2.1">&nbsp;</a></h4>

<p>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 <a href="../struct/tables.html#edef-COLGROUP"><samp class="einst">COLGROUP</samp></a> or <a href="../struct/tables.html#edef-COL"><samp
class="einst">COL</samp></a> elements. The default table width is the
space between the current left and right margins, but may be
overridden by the <a href="../struct/tables.html#adef-width-TABLE"><samp class="ainst-TABLE">width</samp></a> attribute on the
<a href="../struct/tables.html#edef-TABLE"><samp class="einst">TABLE</samp></a> 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.

<p>The table syntax alone is insufficient to guarantee the consistency
of attribute values. For instance, the number of columns specified by
the <a href="../struct/tables.html#adef-cols-TABLE"><samp class="ainst-TABLE">cols</samp></a> attribute may be inconsistent with
the number of columns implied by the <a href="../struct/tables.html#edef-COL"><samp class="einst">COL</samp></a>
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 <a href="../struct/tables.html#edef-TABLE"><samp class="einst">TABLE</samp></a> element or
<a href="../struct/tables.html#edef-COL"><samp class="einst">COL</samp></a> elements may result in overflow of cell
contents. It is recommended that user agents attempt to recover
gracefully from these situations, e.g., by <a
href="../struct/text.html#hyphenation">hyphenating words</a> and
resorting to splitting words if hyphenation points are unknown.

<p>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.

<h4>Autolayout Algorithm<a name="h-13.2.2.2.2">&nbsp;</a></h4>

<p>If the <samp class="einst">COLS</samp> 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.

<p>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. Since line wrap has been disabled,
paragraphs are treated as long lines unless broken by <a href="../struct/text.html#edef-BR"><samp
class="einst">BR</samp></a> elements. The minimum width is given by the
widest text element (word, image, etc.) taking into account leading
indents and list bullets, etc. In other words, it is necessary to
determine the minimum width a cell would require in a window of its
own 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 the cell contents.

<p>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.

<P>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:
<tt>max(min_left + min_right, min_non-aligned)</tt>.

<P>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).

<P>For cells that span multiple columns, a simple approach (as used by
<a href="../references.html#arena">Arena</a>) consists of apportioning the
min/max widths evenly 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. Experiments suggest that
a blend of the two approaches gives good results for a wide range of
tables.

<P>The table borders and intercell margins need to be included in assigning
column widths. There are three cases:

<OL>
<LI><B>The minimum table width is equal to or wider than the available
space.</B> 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.

<LI><B>The maximum table width fits within the available space.</B> In
this case, set the columns to their maximum widths.

<LI><B>The maximum width of the table is greater than the available
space, but the minimum table width is smaller.</B> In this case, find
the difference between the available space and the minimum table width,
lets call it <b>W</b>. Lets also call <b>D</b> the difference between
maximum and minimum width of the table.

<P>For each column, let <b>d</b> be the difference between maximum
and minimum width of that column. Now set the column's width to the
minimum width plus <b>d</b> times <b>W</b> over <b>D</b>. This makes
columns with large differences between minimum and maximum widths wider
than columns with smaller differences.
</OL>

<P>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., englobing) 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.

<P>If the table width is specified with the <a href="../struct/tables.html#adef-width-TABLE"><samp
class="ainst-TABLE">width</samp></a> attribute, the user agent attempts to set
column widths to match. The <a href="../struct/tables.html#adef-width-TABLE"><samp class="ainst-TABLE">width</samp></a> attribute
is not binding if this results in columns having less than their
minimum (i.e., indivisible) widths.

<P>If relative widths are specified with the <a href="../struct/tables.html#edef-COL"><samp
class="einst">COL</samp></a> element, the algorithm is modified to
increase column widths over the minimum width to meet the relative
width constraints. The <a href="../struct/tables.html#edef-COL"><samp class="einst">COL</samp></a> elements should
be taken as hints only, so columns shouldn't be set to less than their