Re: [CSS21] Issues with Ch.17 Tables

Le 23/01/2012 23:40, Anton Prowse a écrit :
> 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.)

9.2.1 says "non-replaced table cells are block containers". (By the way, 
are *replaced* table cells really allowed?) So the 'overflow' property 
applies to cells.

A column width of zero results in a used width of zero for cells (width 
can not be negative). But a cell that has padding and/or borders can 
still overflow indeed. Even a cell with 'overflow: hidden' will still 
have content visible in its padding area, which can overflow the column.

Anyway, I think that these are degenerate cases. When they happen, 
authors should either switch to the automatic layout or fix their 
specified column widths.

> 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.

I don’t see what cell spacing could refer to other than border spacing. 
Agreed that it should be changed or clarified either way.
> 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?

I think that there is no issue here. For example, with two adjoining 
cells in the same row: from left to right, there is the content area of 
the left cell, its right padding, its right border, then the horizontal 
border spacing, then the left border of the right cell, then its left 
padding, etc.

There is no overlap between any of these so it does not matter if both 
borders do not have the same width. Unlike the collapsing border model, 
there is nothing special at half the border width.


> 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.)

I think that in the collapsing border model the border conflict 
resolution needs to happen early, before the layout. This way, by the 
time we care about it, there is only one border between cells i and i+1.

Taking the maximum width is another way to look at it and gives almost 
the same result, except that 'border-style: hidden' should take 
precedence and implies 'border-width: 0'


> 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.

So the height property on table cells refer (as a lower bound) to the 
height of the row, not to the height of its content area? There is no 
problem with that, other than it is inconsistent with every other use of 
the height property.

Unless there is backward-compatibility issues with existing content, I 
think this should be changed: The 'height' property would refer the the 
height of the content area of the cell. Add the top and bottom padding 
and borders to get the "border height" of the cell. That border height 
is used as a lower bound for the row.

Also, the fixed layout has exactly the same issue with the 'width' 
property on cells of the first row.


> 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?

I thing it is not taken into account with the current spec text, but it 
should. See issue 5.

More generally, the width and height properties should refer to what 
will end up as the cell’s content area, and do the Right Thing® with 
respect to padding and borders (and which border model is used.)

(Similar opinion for other combinations of layout and border model.)


Anyway, thanks Anton for tracking all these.

Regards,
-- 
Simon Sapin

Received on Tuesday, 24 January 2012 13:02:31 UTC