rfc1942.txt

RFC 的详细文档！

   in the TABLE start tag.

   Authors still need a way of informing the browser whether to use
   incremental display or to automatically size the table to match the
   cell contents. For the two pass auto sizing mode, the number of
   columns is determined by the first pass, while for the incremental
   mode, the number of columns needs to be stated up front. So it seems
   to that COLS=_nn_ would be better for this purpose than a LAYOUT
   attribute such as LAYOUT=FIXED or LAYOUT=AUTO.

   It is generally held useful to consider documents from two
   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 to
   separate the structural information in documents from rendering
   information. Mixing them together ends up causing increased cost of
   ownership for maintaining documents, and reduced portability between
   applications and media.

   For tables, the alignment of text within table cells, and the borders
   between cells are, from the purist's point of view, rendering
   information. 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 is
   designed to take advantage of such style sheets but not to require



Raggett                       Experimental                      [Page 6]

RFC 1942                      HTML Tables                       May 1996


   them.

   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.

   Following the CALS table model, 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.

   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.

   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 FRAME attribute controls the appearence of the border
   frame around the table while the RULES attribute determines the
   choice of rulings within the table.

   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 FRAME and RULES 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.



Raggett                       Experimental                      [Page 7]

RFC 1942                      HTML Tables                       May 1996


A walk through the table DTD

   The table document type definition provides the formal definition of
   the allowed syntax for html tables. The following is an annotated
   listing of the DTD. The complete listing appears at the end of this
   document.

   Note that the TABLE element is a block-like element rather a
   character-level element. As such it is a peer of other HTML block-
   like elements such as paragraphs, lists and headers.

Common Attributes

   The following attributes occur in several of the elements and are
   defined here for brevity. In general, all attribute names and values
   in this specification are case insensitive, except where noted
   otherwise. The ID, CLASS and attributes are required for use with
   style sheets, while LANG and DIR are needed for internationalization.

   <!ENTITY % attrs
          "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 --">

   ID
       Used to define a document-wide identifier. This can be used for
       naming positions within documents as the destination of a
       hypertext link. It may also be used by style sheets for
       rendering an element in a unique style. An ID attribute value is
       an SGML NAME token. NAME tokens are formed by an initial letter
       followed by letters, digits, "-" and "." characters. The letters
       are restricted to A-Z and a-z.

   CLASS
       A space separated list of SGML NAME tokens. CLASS names specify
       that the element belongs to the corresponding named classes. It
       allows authors to distinguish different roles played by the same
       tag. The classes may be used by style sheets to provide
       different renderings as appropriate to these roles.

   LANG
       A LANG attribute identifies the natural language used by the
       content of the associated element.The syntax and registry of
       language values are defined by RFC 1766. In summary the language
       is given as a primary tag followed by zero or more subtags,
       separated by "-". White space is not allowed and all tags are
       case insensitive. The name space of tags is administered by



Raggett                       Experimental                      [Page 8]

RFC 1942                      HTML Tables                       May 1996


       IANA. The two letter primary tag is an ISO 639 language
       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.

   DIR
       Human writing systems are grouped into scripts, which determine
       amongst other things, the direction the characters are written.
       Elements of the Latin script are nominally left to right, while
       those of the Arabic script are nominally right to left. These
       characters have what is called strong directionality. Other
       characters can be directionally neutral (spaces) or weak
       (punctuation).

       The DIR attribute specifies an encapsulation boundary which
       governs the interpretation of neutral and weakly directional
       characters. It does not override the directionality of strongly
       directional characters. The DIR attribute value is one of LTR
       for left to right, or RTL for right to left, e.g. DIR=RTL.

       When applied to TABLE, it indicates the geometric layout of rows
       (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 in
       the table's content if no other DIR attribute applies to that
       text.

Horizontal and Vertical Alignment Attributes

   The alignment of cell contents can be specified on a cell by cell
   basis, or inherited from enclosing elements, such as the row, column
   or the table element itself.

   ALIGN
       This specifies the horizontal alignment of cell contents.

   <!-- 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 --"
           >

       The attribute value should be one of LEFT, CENTER, RIGHT,
       JUSTIFY and CHAR. User agents may treat JUSTIFY as left
       alignment if they lack support for text justification.
       ALIGN=CHAR is used for aligning cell contents on a particular
       character.



Raggett                       Experimental                      [Page 9]

RFC 1942                      HTML Tables                       May 1996


       For cells spanning multiple rows or columns, where the alignment
       property is inherited from the row or column, the initial row
       and column for the cell determines the appropriate alignment
       property to use.

       Note that an alignment attribute on elements within the cell,
       e.g. on a P element, overrides the normal alignment value for
       the cell.

   CHAR
       This is used to specify an alignment character for use with
       align=char, e.g. char=":". The default character is the decimal
       point for the current language, as set by the LANG attribute.
       The CHAR attribute value is case sensitive.

   CHAROFF
       Specifies the offset to the first occurrence of the alignment
       character on each line. If a line doesn't include the alignment
       character, it should be horizontally shifted to end at the
       alignment position. The resolved direction of the cell, as
       determined by the inheritance of the DIR attribute, is used to
       set whether the offset is from the left or right margin of the
       cell. For Latin scripts, the offset will be from the left
       margin, while for Arabic scripts, it will be from the right
       margin. In addition to standard units, the "%" sign may be used
       to indicate that the value specifies the alignment position as a
       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 alignment
       position in the absence of an explicit or inherited CHAROFF
       attribute can be determined by choosing the position that would
       center lines for which the width before and after the alignment
       character are at the maximum values for any of the lines in the
       column for which ALIGN=CHAR. For incremental table layout the
       suggested default is CHAROFF="50%". If several cells in
       different rows for the same column use character alignment, then
       by default, all such cells should line up, regardless of which
       character is used for alignment. Rules for handling objects too
       large for column apply when the explicit or implied alignment
       results in a situation where the data exceeds the assigned width
       of the column.

   VALIGN
       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


       <!-- vertical alignment attributes for cell contents -->
       <!ENTITY % cell.valign
               "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 with
       valign=baseline should be vertically positioned so that the
       first text line in each such cell occur on a common baseline.
       This constraint does not apply to subsequent text lines in these
       cells.

Inheritance Order

   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 the
   columns. The following table gives the detailed precedence order for
   each attribute, where X > Y denotes that X takes precedence over Y:

   ALIGN, CHAR and CHAROFF:

   cells > columns > column groups > rows > row groups > default

   VALIGN, LANG, and DIR:

   cells > rows > row groups > columns > column groups > table > default

   Where cells are defined by TH and TD elements; rows by TR elements;
   row groups by THEAD, TBODY and TFOOT elements, columns by COL
   elements; and column groups by COLGROUP and COL elements. Note that
   there is no inheritance mechanism for the CLASS attribute.

   Properties defined on cells take precedence over inherited
   properties, but are in turn over-ridden by alignment properties on
   elements within cells. In the absence of an ALIGN attribute along the
   inheritance path, the recommended default alignment for table cell
   contents is ALIGN=LEFT for table data and ALIGN=CENTER for table
   headers. The recommended default for vertical alignment is
   VALIGN=MIDDLE. These defaults are chosen to match the behaviour of
   the widely deployed Netscape implementation.

Standard Units for Widths

   Several attributes specify widths as a number followed by an optional
   suffix. The units for widths are specified by the suffix: pt denotes
   points, pi denotes picas, in denotes inches, cm denotes centimeters,