Re: CSS2 Table Model

L. David Baron writes:
 > I have some questions and comments on the CSS2 chapter on tables [1],
 > which I recently read (almost) all the way through for the first time:

I think we should make it a requirement that David reads our drafts
before we can make them Recommendations :-)

 > 
 > * Section 17.4.1 says that percentage widths for top or bottom captions
 > are computed relative to the table box's containing block.  What about
 > percentage heights?  And side captions?

A percentage on the 'width' property always refers to the containing
block (see 10.2), and that is no different for captions. The sentence
in 17.4.1 only wants to say something about the 'auto' value, which
has different meaning for side captions than for top/bottom captions.

Percentage heights are likewise covered by the definition of 'height'
(10.5): if the caption's "containing block" has an explicit height
(i.e., not 'auto'), then the height is a percentage of that, otherwise
the percentage is ignored and the height is treated as 'auto'.

 > 
 > * Also in section 17.4.1, do auto side margins on side captions become
 > zero?  Or is there some way to center both table and caption?

You are referring to a style sheet like this?

    CAPTION {
        caption-side: left;
        width: <something>;
        margin-left: auto;
        margin-right: auto
    }

The text doesn't say :-(

My interpretation: There is nothing to constrain the width of the
caption in this case. The width is computed purely "bottom-up" (or
"inside-out": the content rather than the context determines the
size). It is somewhat similar to a float in that respect. So, by
analogy, I would indeed expect the margins to be treated as 0.

(Note that in this case the left margin has no function anyway,
whatever its value.)

What do you mean by "centering a side caption": center w.r.t. what?

 > 
 > * What areas are covered by column, row, column-group, and row-group
 > backgrounds (17.5.1)?  Specifically, do the backgrounds of two adjacent
 > rows, columns, etc., cover the cell-spacing between those rows in the
 > separated borders model?  (I would think not even though it seems to
 > contradict 17.5.1, but I'm not sure)  Do they cover the space where a
 > transparent / dotted / dashed border would be in the collapsing border
 > model?  (I would think so.)  This was asked before [2], but never
 > answered officially.

First the collapsed border model:

The rows completely cover the table, there are no gaps between the
rows. So if all the rows have a non-transparent background, you cannot 
see the table background at all. Ditto for row groups.

For columns the situation is slightly more complex, since column
elements are optional, so there may be columns in the table with no
corresponding column element. But when there are column elements on
adjacent columns, they also leave no gaps between them.

If there is a non-solid border (such as dotted), the question is then
which background you see between the dots. Borders are centered on the 
grid lines (see 17.6.2), so you see exactly half of one background and 
half of the other background.

The separated borders model is less well specified:

Although 17.5.1 says that the rows and columns cover the whole table,
17.6.1 says that the space between the borders shows the table
background, and not the row or column background. This is a
contradiction...

I think the CSS WG has to discuss this.

 > 
 > * Section 17.5.2, Automatic Table Layout, the first ordered list, item
 > 2 should mention that string values for text-align could make the
 > minimum column width larger than the largest minimum cell width
 > (probably only if all cells involved could not be broken, since string
 > alignment doesn't work when the cells have line-breaks)

That's correct. If some cells have a string-valued 'text-align'
property, you should separately find the minimum width to the left of
that string and to the right of it.

I'll propose it for an erratum.

 > 
 > * Should section 17.5.3 say that length and percentage values of
 > vertical-align should also be equivalent to baseline, since they
 > do not apply to cells?

Yes.

 > 
 > * Section 17.5.3 doesn't define height on table-row-group (or
 > table-header-group or table-footer-group).  Should it be defined in the
 > same way as height for table in the first paragraph?  The definition in
 > chapter 10 [3] clearly doesn't fit.

No, I think it should be defined in the same way as the height of
rows, in the 2nd paragraph. But I agree this is missing.

 > 
 > * Section 17.5.3 doesn't mention padding at all.  Should it be
 > mentioned in the second paragraph, when describing how to find the
 > height of a row?

Padding is implicitly included in the height of the cell box (see 8.1, 
except that margin doesn't apply to cell boxes). It could be
mentioned, but it is not an error.

 > 
 > * Section 17.5.4 says that "CSS does not provide a way specify the
 > offset of the vertical alignment axis with respect to the edge of a
 > column box."  However, where should this axis go?  If the with for the
 > column needed by the cells aligned to the axis is smaller than the
 > actual column width, towards which edge (or to the middle) should the
 > axis be pushed?  In the example, right is used, but I don't see why.

There is no reason. CSS indeed doesn't say where the text goes if
there are multiple possibilities. Should it? And if so, what should it
say?

 > 
 > * The border collision rules (17.6.2) are ambiguous when borders differ
 > only in color and the conflicting borders are on adjacent cells, or
 > adjacent rows, etc.  I think a rule such as:
 > 
 >   5. the border on the element earlier in the document tree wins
 > 
 > would be good.  (I chose earlier because of table-header-groups and
 > table-footer-groups.)

That would indeed solve the ambiguity. (Or rather: make it defined,
since it is not ambiguous, but simply undefined.)

 > 
 > * In section 17.6.3, are the definitions of inset and outset borders
 > backwards?  I would think that, in the collapsing borders model, inset
 > should be the same as ridge, since two inset cells should have a ridge
 > between them, whereas two outset cells should have a groove between
 > them.

You're right. They are backwards :-(



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Monday, 26 July 1999 15:09:29 UTC