W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[CSS21] Issues with Ch.17 Tables

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 23 Jan 2012 23:40:39 +0100
Message-ID: <4F1DE1E7.8000100@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
In addition to the items being discussed in contemporary posts, here are 
some more issues with the Tables chapter in CSS21.


Issue 1:

In the fixed table layout algorithm, columns may end up with very small 
or zero width.  The column determines the maximum width of its cells, 
but what happens when the cell has horizontal padding which is greater 
than the column width?  Presumably the cell overflows the column, but 
note that the 'overflow' property only applies to block containers and 
so, in particular, it doesn't apply to columns or column-groups.  This 
seems like an odd situation.  (The same situation may arise with cell 
borders in the separated borders model.)


Issue 2:

The term "cell spacing" is used in 17.5.2.1 (Fixed table layout), 
17.5.2.2 (Automatic table layout) and 17.5.3 (Table height algorithms). 
  Does this refer to the spacing determined by the 'border-spacing' 
property?  If so, the spec ought to be more consistent since 17.6.1 (The 
separated borders model) and 17.6.1.1 both use the term "border spacing" 
instead.


Issue 3:

17.6.1 (The separated borders model) says:

   # The 'border-spacing' property specifies the distance between
   # the borders of adjoining cells.

Different cells might have different border widths, so this property 
actually specifies the (sharp) *minimum* distance, right?


Issue 4:

17.6.2 (The collapsing border model) says:

   # The diagram below shows how the width of the table, the widths
   # of the borders, the padding, and the cell width interact. Their
   # relation is given by the following equation, which holds for
   # every row of the table:
   #
   #    row-width = (0.5 * border-width_0) + padding-left_1 +
   #                 width_1 + padding-right_1 + border-width_1 +
   #                  padding-left_2 +...+ padding-right_n +
   #                   (0.5 * border-width_n)
   #
   # Here n is the number of cells in the row, padding-left_i and
   # padding-right_i refer to the left (resp., right) padding of
   # cell i, and border-width_i refers to the border between
   # cells i and i + 1.

But what does "the border between cells i and i + 1" actually mean?  Is 
it the maximum of all the relevant individual border widths (cell, 
column, column-group) between the two cells? (This would seem to play 
nicely with border conflict resolution.)


Issue 5:

17.5.3 (Table height algorithms) says:

   # The height of a 'table-row' element's box is calculated once
   # the user agent has all the cells in the row available: it is
   # the maximum of the row's computed 'height', the computed
   # 'height' of each cell in the row, and the minimum height (MIN)
   # required by the cells.

This is a little surprising.  MIN includes cell borders and padding, 
whereas the computed 'height' of each cell doesn't.  There's no 
theoretical problem with this, but I thought it worth drawing attention to.


Issue 6:

There is a general class of issues regarding the fact that the 
automatic, fixed and height layout algorithms desperately try to be 
agnostic to the particular borders model being used, but do not 
satisfactorily succeed.

I think that a better approach would be for each of these sections to 
have a leading paragraph explaining the influence of each of the two 
borders models on the subsequent calculations which can refer back to 
the information in that paragraph when necessary.

a) 17.5.2.1 (Fixed table layout) says:
   # 2. Otherwise, a cell in the first row with a value other than
   #    'auto' for the 'width' property determines the width for
   #    that column.
How, exactly? Is the cell's padding taken into account?

b) 17.5.2.1 (Fixed table layout) talks vaguely about borders.  In the 
case of the the collapsed borders model, is it referring to the border 
lumps made up of cell and column borders?  (See also Issue 4 above.)  In 
the case of the the separated borders model, there are no column borders 
to consider; are the cell borders accounted for when determining the 
column widths (since columns contain cell borders in this borders 
model)?  Cf. (a) above.

c) 17.5.2.2 (Automatic table layout) also talks vaguely about borders. 
In the case of the separated borders model columns are supposed to 
contain cell borders, yet that doesn't seem to be the case here unless 
the "minimum cell width" in steps 2 and 3 of the column width 
calculation refers to outer width (in contrast with how that term is 
defined in step 1).  It looks as if the algorithm is simply assuming the 
collapsed borders model.  Is this interpretation correct?

d) 17.6.2 (Collapsing border model) doesn't talk about horizontal 
borders (other than table top and table bottom) and 17.5.3 (Table height 
algorithms) merely says:
   # A value of 'auto' means that the [table] height is the sum of
   # the row heights plus any cell spacing or borders.
More explanation might be needed here.  (See also Issue 4 above.)

[1] http://lists.w3.org/Archives/Public/www-style/2008Mar/0148.html

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 23 January 2012 22:41:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT