So, let me be the first to select from the list the options that I
would like. Maybe that will entice others to make their needs and
wishes known.
[1]: <http://www.acl.lanl.gov/HTML_WG/html-wg-95q2.messages/0522.html>
[...]
|* B. FEATURES
|
|In principle, if the mark up includes enough hooks (in the form of
|CLASS attributes or otherwise), any lay out can be specified with
|style sheets. However, it may be desirable to include some formatting
|in the mark up, either for ease of use, or because some of it is
|arguably part of the semantics of the table (see item 12 above).
|
|Here is a list of the features that have been mentioned as belonging
|in the mark up. Note that this is just a list of features, how they
|appear in the syntax is not of concern here.
|
|The idea is to check off subsets of these: one for HTML 2.1, another
|with what we expect to add later, and the rest that we can leave to
|style sheets or other applications. Note that an empty set is also a
|set!
|
|** 1. Column widths
|
| a. Relative column widths (i.e., relative to other columns, not to
| anything outside the table).
YES
|
| b. Table width relative to page width (as a percentage of the space
| between the current margins, or something similar).
YES
I would be content with these two. Specifying relative columns widths
together with the width of the whole table relative to the page width,
would allow a formatter to compute column widths in one pass.
|
| c. Absolute table width, in real world units:
| I. cm; II. mm; III. dm; IV. inch; V. point; VI. pica;
NO
|
| d. Fixed table width, in units that derived from something
| (virtually) inside the table. The units will be something like
| the body size or em of a designated default font.
NO
|
| e. Device dependent width in pixels (but what is a pixel if the
| output is a laser printer?)
NO
|
| e. Automatic column and table width, using some algorithm that
| finds a compromise between the columns' minimum and maximum
| widths and the current page width.
NO
|
| f. A mixture of the above, in the sense that some columns are given
| an absolute or fixed width, while the rest is sized
| automatically.
NO
|
| g. Allow fractional numbers (1.5) and/or scientific notation (2.3E-2)
| in any of the above.
NO
|
|** 2. Vertical alignment of a cell within a row
|
| a. top
YES
|
| b. middle
YES
|
| c. bottom
YES
|
| d. baseline: the baseline of the first line in the cell is aligned
| with the baselines of the first lines of all other cells in the
| same row. Note that this depends on other cells in the row and
| is therefore ambiguous if some cells in the row have a different
| alignment.
NO
|
| e. some offset from the top (percentage or otherwise).
NO
|
|** 3. Horizontal alignment of a cell within a column
|
| a. Assume that this really means: alignment of the text within the
| cell. Note that this can be no more than a *default* alignment,
| it is still possible to put a left aligned paragraph inside a
| cell; the paragraph as a whole will be right aligned inside the
| cell, but each of the lines will be left aligned inside the
| paragraph.
YES
|
| b. left
YES
|
| c. center
YES
|
| d. right
YES
|
| e. decimal, on the decimal separator of the current language. Note
| (1) that this means that the formatter needs to know more about
| a cell than just the width; and (2) that this assumes the cell
| contains text, not other elements.
YES
|
| f. align on an arbitrary character
YES
|
| g. (e) or (f) combined with an offset from the left
NO
|
| h. some offset from the left
NO
|
| i. flag to (dis)allow line breaking inside the cell (see the note
| in (a) above).
NO
|
|** 4. Horizontal rules
|
| a. just an on/off switch (on = rules on the top and after every
| row, off = no rules at all)
YES
|
| b. typed rules (none, single, thick, double, 3D raised, 3D sunken,
| stippled, etc.)
NO
|
| c. thickness of rule in pixels
NO
|
| d. thickness in absolute units (point, mm, etc)
NO
|
| e. thickness of rule in fixed units (font size)
NO
|
| f. parameters for other aspects of a rule (gap between double rule,
| width of 3D bevel, etc.)
NO
|
| g. rules tied to special positions: top of table, bottom of table,
| between header and body, between body and footer, between all
| other rows.
NO
|
| h. rules below individual rows (either by numbering the rows, or by
| inserting a rule at the appropriate place (an <HR> element or an
| attribute).
MAYBE
|
|** 5. Inter-row spacing
|
| a. compact/loose flag (analogous to the COMPACT attribute on lists)
YES
|
| b. absolute spacing (real world units, such as cm, mm, inch, point)
NO
|
| c. fixed spacing (relative to some default font)
NO
|
| d. (a), (b) or (c) tied to special positions (top, bottom, between
| head and body, between body and foot, everywhere else)
NO
|
| e. (a), (b) or (c) tied to individual rows (either by row number or
| with an attribute of the row)
NO
|
| f. Mark rows as possible places for a page break (for output on
| paper).
NO
|
|** 6. Column and row spanning, nested tables
|
| a. span columns
YES
|
| b. span rows
YES
|
| c. allow nested tables
MAYBE
|
| d. non-rectangular cells
NO
|
|** 7. Overlapping cells (only possible if 6b or 6d is checked)
|
| a. formulate the rules in such a way that cells cannot overlap (the
| simplest is to say that cells automatically move to the right
| until they fit).
YES
|
| b. allow overlapping cells and declare them to be meaningful.
NO
|
| c. allow overlapping cells in the syntax, but declare them
| (semantically) invalid.
NO
|
|** 8. Vertical rules
|
| a. just an on/off switch
YES
|
| b. typed rules (none, single, thick, double, 3D, stippled, etc.)
NO
|
| c. thickness in pixels
NO
|
| d. thickness in absolute units (point, mm, etc.)
NO
|
| e. thickness of rule in fixed units (font size)
NO
|
| f. parameters for other aspects of a rule (gap between double rule,
| width of 3D bevel, etc.)
NO
|
| g. rules tied to special positions: left of table, right of table,
| between columns.
NO
|
| h. rules after individual columns.
NO
|
|** 9. Inter-column spacing
|
| a. compact/loose flag (analogous to the COMPACT attribute on lists)
YES
|
| b. absolute spacing (real world units, such as cm, mm, inch, point)
NO
|
| c. fixed spacing (relative to some default font)
NO
|
| d. (a), (b) or (c) tied to individual columns
NO
|
| e. inter-column spacing takes priority over column width (see
| section 1 above, not always possible)
NO
|
| f. a conflict between inter-column spacing and column width renders
| the table invalid (and the result undefined).
NO
|
|** 10. Abstract model
|
| a. attributes to allow translation from the 2D lay out to an
| abstract n-dimensional representation (and from there to, e.g.,
| braille or speech). This means that cells can have one of two
| roles: they either mark a point on an axis or attach a value to
| an n-tuple (a point in an n-dimensional space).
YES
|
| b. allow a cell to fulfill both roles at the same time.
MAYBE
|
| c. add rules to make a default translation possible (that is, if no
| explicit dimensions are given, allow the table to be interpreted
| as a set of values attached to points in 2 dimensions).
YES
|
| d. rules for the syntax of these attributes. An example of such a
| syntax could be: the AXIS attribute is of the form
| DIMENSION=VALUE and the AXES attribute is of the form "DIM1=VAL1
| DIM2=VAL2...".
YES
|
|
|
|* C. DEFAULTS
|
|For each of the above features, we may want to specify a default. How
|many defaults are needed depends on the syntax, of course. We may have
|to do this section again once the syntax is fixed.
|
| a. TD cells are left aligned
MAYBE
|
| b. TD cells are left aligned if the language at the start of the
| table is written left to right.
YES
|
| c. TH cells are centered
YES
|
| d. TH cells are left aligned
MAYBE
|
| e. TH cells are left aligned if the language at the start of the
| table is written left to right.
MAYBE
|
| f. all columns have the same width
YES
|
| g. a table is as wide as the current line length
YES
|
| h. no borders
YES
|
| i. cells are aligned at the top
YES
|
| j. cells are centered vertically
MAYBE
|
| k. if units are needed, the default is point
NO
|
|
|
|* D. SYNTAX
|
|Some parts of the syntax are not controversial or not important enough
|to fight over. Among those are the names of elements and attributes
|(but see A4). Also in this group is the fact that a TABLE contains
|only a single table, and the fact that a TFOOT (if present) comes at
|the end.
|
|** 0. Basic structure
|
| a. No table headers and footers: <!ELEMENT TABLE - - (CAPTION?, TR+)>
|
| "*" instead of "+" is also acceptable
YES
|
| b. With headers and footers:
| <!ELEMENT TABLE - - (CAPTION?, THEAD?, TBODY, TFOOT?)>
MAYBE
|
|** 1. Column widths
|
| a. A #required COLWIDTH attribute on TABLE, containing
| numbers, as many as there will be columns.
YES
|
| b. An #implied COLWIDTH attribute on TABLE, containing numbers, not
| necessarily as many as there are columns.
MAYBE
|
| c. A UNITS attribute on TABLE, to qualify the numbers in COLWIDTH
NO
|
| d. An #implied COLWIDTH attribute that contains both numbers and
| units. (Note that this may introduce ambiguities: what happens
| if units and dimensionless widths are used together?)
NO
|
| I. ditto, with abbreviations, e.g., "2 2 & 2 1" = repeat the
| pair "2 1" as often as needed (cf. TeX); or "2 2 15*1" =
| repeat the "1" fifteen times.
NO
|
| e. COLWIDTH and/or UNITS attributes not on the TABLE, but on empty
| TSPEC elements inserted between CAPTION and THEAD, one TSPEC for
| every column.
NO
|
|** 2. Vertical alignment
|
| a. A single VALIGN attribute on the TABLE.
MAYBE
|
| b. (in the case of 2) A VALIGN attribute on each of THEAD, TBODY
| and TFOOT.
MAYBE
|
| c. A VALIGN on each TR.
MAYBE
|
| d. For each of a-c: allow abbreviations (as for column widths, see
| above)
NO
|
| e. A VALIGN on each TD and TH.
YES
|
| f. A combination of a, b, c and e, with later ones having higher
| priority.
MAYBE
|
| g. VALIGNs on TSPEC elements, that refer to a cell by virtue of
| having the same CLASS attribute.
NO
|
| h. VALIGNs on TSPEC elements, that also have an attribute to refer
| to a row by number, or to several rows, by means of a list or a
| range of numbers.
NO
|
|** 3. Horizontal alignment
|
| a. an HALIGN attribute on TABLE, with a (one-letter) alignment
| specification for each column (defaults apply if there are too
| few specifications; what happens if there are too many?)
MAYBE
|
| b. an HALIGN attribute on each of THEAD, TBODY and TFOOT.
MAYBE
|
| c. an HALIGN on each TR.
NO
|
| d. an HALIGN on each TD or TH.
YES
|
| e. a combination of a-d, with later ones having higher priority
| (Note: if a later HALIGN has fewer columns than an earlier one,
| the remaining columns get the default alignment, not the
| alignment specified by the earlier HALIGN).
MAYBE
|
| f. HALIGNs on TSPEC elements, that apply to cells with the same
| CLASS as the TSPEC.
NO
|
| g. HALIGNs on TSPECs, with as many TSPEC as there are columns.
NO
|
| h. Ditto, but with TSPECs referring to columns by number, list of
| numbers and/or number range.
NO
|
| i. a CHAR attribute on TSPECs, to indicate which character to align
| on.
NO
|
| j. a CHAR attribute on each TD and TH, to indicate which character
| to align on.
YES
|
| k. both (i) and (j), with later ones having higher priority.
NO
|
|** 4. Horizontal rules
|
| a. a single, boolean HRULES (or BORDER) attribute on TABLE.
YES
|
| b. an attribute that specifies the rules between rows in some
| syntax (e.g., "top bottom" for rules only above and below the
| table, single-letter values are possible as well).
NO
|
| c. (a) or (b), but with keyword values, such as "single", "double",
| "thick".
NO
|
| d. (a) or (b), but with numerical values
| I. dimensionless, but higher numbers mean thicker lines
| II. with units
NO
|
| e. a boolean attribute HRULE on each TR, to insert a rule below the
| row (and an attribute on TABLE to insert a rule above the first
| row).
MAYBE
|
| f. an HRULE attribute on each TR, but with keyword values.
NO
|
| g. ditto, but with a numerical value
| I. dimensionless, but higher numbers mean thicker lines
| II. with units
NO
|
| h. an empty element HRULE (or HR?) between rows (possibly with an
| attribute)
MAYBE
|
|** 5. Inter-row spacing
|
| a. A single, boolean COMPACT attribute on TABLE
YES
|
| b. A numerical attribute (ROWSEP?) on TABLE (with units).
NO
|
| c. A numerical attribute on each of THEAD, TBODY and TFOOT.
NO
|
| d. A numerical attribute on each TR.
NO
|
| e. (b), (c) and (d), with later ones having higher priority.
NO
|
| f. an attribute on TSPECs, which refer to rows by virtue of having
| the same CLASS as a TR element
NO
|
| g. an attribute on TSPECs, that refer to a row by a number, a list
| of numbers, and/or a range of numbers
NO
|
|** 6. Column and row spanning, nested tables
|
| a. a COLSPAN attribute on each TD and TH
YES
|
| b. a ROWSPAN attribute on each TD and TH
YES
|
| c. allow TABLE in the content model of TD and TH
MAYBE
|
|** 7. (intentionally left blank)
|
|** 8. Vertical rules
|
| a. a single, boolean VRULES attribute on TABLE (can be combined
| with 4a, and change its name to BORDER).
YES
|
| b. some syntax to specify left and right edge independently from
| internal rules.
NO
|
| c. (a) or (b) with keywords ("s", "single", "d", "double", etc.)
NO
|
| d. (a) or (b) with numbers
| I. dimensionless, higher numbers mean thicker lines
| II. with units
NO
|
| e. A combination with COLWIDTH, mix numbers and letters (or numbers
| and vertical bars, as in TeX)
NO
|
| f. An extra attribute on the TSPECs as meant in 1e above.
NO
|
|** 9. Inter-column spacing
|
| a. A single, boolean COMPACT attribute on TABLE (combined with 5a
| above)
YES
|
| b. A numerical attribute (COLSEP?) on TABLE (with units).
NO
|
| f. an attribute on the TSPECs as meant in 1e above.
NO
|
| g. an attribute on TSPECs, that refer to a column by a number, a list
| of numbers, and/or a range of numbers
NO
|
| h. combine with inter-row spacing into a single attribute for both
| horizontal and vertical spacing between cells (CELLSPACING?)
NO
|
|** 10. Abstract model
|
| a. AXIS (CDATA) attribute on each TH
YES
|
| b. AXES (CDATA) attribute on each TD
YES
|
| c. both AXIS and AXES on TD and TH
MAYBE
The DTD fragment could look like this:
<!ENTITY % horiz.align "left|center|right|justify">
<!ENTITY % vert.align "top|middle|bottom">
<!ELEMENT table - - (caption?, thead?, tbody, tfoot?)>
<!ATTLIST table
cols NUMBERS #REQUIRED -- relative widths of columns --
width NUMBER 100 -- percentage of page width --
hrules (hrules) #IMPLIED -- horizontal rules between rows --
vrules (hrules) #IMPLIED -- vertical rules between columns --
compact (compact) #IMPLIED -- reduce spacing between cells --
valign (%vert.align) top -- default vertical alignment for cells --
%block.align; -- horizontal alignment of table --
%attrs; -- id, lang, class --
%needs; -- clear --
>
<!ELEMENT (thead|tbody|tfoot) - - (tr+)>
<!ATTLIST (thead|tbody|tfoot)
valign (%vert.align) #IMPLIED -- default vertical alignment for cells --
halign (%horiz.align) #IMPLIED -- horizontal alignment --
dp CDATA #IMPLIED -- default decimal point e.g. dp="," --
%attrs; -- id, lang, class --
>
<!ELEMENT tr - O (TH | TD)*>
<!ATTLIST tr
valign (%vert.align) #IMPLIED -- default vertical alignment for cells --
%attrs; -- id, lang, class --
>
<!ELEMENT th - O (%body.content)*>
<!ATTLIST th
colspan NUMBER 1 -- columns spanned --
rowspan NUMBER 1 -- rows spanned --
valign (%vert.align) #IMPLIED -- vertical alignment --
halign (%horiz.align) #IMPLIED -- horizontal alignment --
dp CDATA #IMPLIED -- decimal point e.g. dp="," --
axis CDATA #IMPLIED -- axis name --
%attrs; -- id, lang, class --
>
<!ELEMENT td - O (%body.content)*>
<!ATTLIST td
colspan NUMBER 1 -- columns spanned --
rowspan NUMBER 1 -- rows spanned --
halign (%horiz.align) #IMPLIED -- horizontal alignment --
valign (%vert.align) #IMPLIED -- vertical alignment --
dp CDATA #IMPLIED -- decimal point e.g. dp="," --
axes CDATA #IMPLIED -- comma separated axes names --
%attrs; -- id, lang, class --
>
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN