Please ingnore CELLPADDING and CELLSPACING which derive from the table
model used by Netscape 1.1. I have removed them in the later proposal
posted to tables@sgmlopen.org and html-wg@oclc.org, following comments
suggesting that this info should really be left to the style sheet.
> bsd: I am in agreement with Harvey Bingham on the units issue.
For the next release of HTML I would like to err on the side of
caution and stick to relative widths, with the possibility of
adding absolute units when we have more experience on using web
browsers with style sheets.
> bsd: What is "baseline" vertical alignment?
This allows you to align the text baselines of cells on the same row
and is supported by Netscape 1.1.
> bsd: What purpose is the 'nowrap' attribute intended to serve?
Its useful when the author wants explicit control over where the
browser should break lines. Unconditional line breaks can be
introduced with <BR> and conditional line breaks using the &cbsp; entity
(conditional breaking space).
> bsd: When nowrap is set, and the width of the cell contents exceeds
> the specified width of the cell, should the cell width expand to the
> length of the cell contents displayed as a single line, or should it
> be truncated, spill over into the right column, or hscroll?
In the core HTML3 table model the cell widths are guaranteed to be
sufficient to fit the cell contents. Users may need to horizontally
scroll the window for tables which are too large to fit in the current
window size. Remember, the font sizes and the window size are controlled
by the user not the author - thats what we want style sheets for.
If we introduce absolute column widths into HTML, browsers could choose
to ignore them or interpret them as relative widths if the cells prove
too small. This need for some kind of error recovery is what I avoided
by going for a two pass rendering algorithm for the core table model.
> bsd: Am I correct in assuming that the 'col' and 'row' attribute
> values specify an intersection of affected cells, and not the
> union of affected cells? For example, in a 3x3 table, would
> <tspec col="2" row="2"> apply to one cell (2,2), or would it apply
> to all cells in column 2 and all cells in row 2?
You got first time - its the intersection of affected cells.
> bsd: tspec is a powerful generalization. It would be useful to have a
> symbolic way to indicate that a col or row range extends to the "end"
> of the range.
Yes - this could be done by allowing authors to omit either the first
or last row or column numbers in a range, e.g. col="2.." for the 2nd to
the last column; col="..3" for the first three columns. However, Harvey's
suggestion of -1 to denote last would be fine for most cases.
Note that I feel that binding tspec elements to groups of cells will
be more convenient if we use matching on class names than with row
and column numbers. This would simply the code for wysiwyg editors.
Perhaps we need both to support CALS more easily?
> Another possibility would be to allow symbols like row="thead../thead",
> to indicate that all columns in the thead would be affected without
> having to enumerate the exact row numbers.
This is very much in the direction of binding by class names as suggested
in my last posting.
> bsd: By allowing users to specify width at the cell level, is it your
> intent to enable users to specify tables whose cells have no
> "columnar" relationship to cells above and below (because there would
> not necessary be cells above or below whose left edge shared the same
> position in the x-dimension)? In other words, do you want to enable
> users to create tables like the one below:
> +----------------------+
> | 1,1 | 1,2 |
> +----------------------+---+
> | 2,1 | 2,2 | 2,3 |
> +--------------------------+
> | 3,1 |
> +--------+
No that isn't the intention. Instead, the idea was to give the
autosizing algorithm better information upon which to choose good
column widths. I suggest you try out Netscape 1.1 and experiment
with this feature.
I feel that if we provide an adequate means to specify relative
widths then indeed this attribute should be removed to avoid confusion.
> bsd: What is the implied semantic difference between TH and TD?
I felt that distinction between header and data seems such a common
case that it justifies using different tags for conciseness.
You can use the class attribute for more detailed distinctions and
indeed this is how I feel we should bind style info on cell borders,
default fonts and background color etc.
Thanks for your comments.
-- Dave Raggett <dsr@w3.org> url = http://www.hpl.hp.co.uk/people/dsr
Hewlett Packard Laboratories, Filton Road, | tel: +44 117 922 8046
Bristol BS12 6QZ, United Kingdom | fax: +44 117 922 8924