Re: [CSS21] Issues with Ch.17 Tables

On 24/01/2012 14:01, Simon Sapin wrote:
> Le 23/01/2012 23:40, Anton Prowse a écrit :
>> 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.)

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

Degenerate or not, they need specifying one way or the other!


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

Actually, my point was that the space visible between the borders of 
different pairs of horizontally-adjacent cells isn't constant throughout 
the table.


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

Indeed, I too imagine that, in practice, border calculations happen very 
early on.  This should probably be made explicit.

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

Indeed.


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

I wouldn't be at all surprised if there were backward-compatibility 
issues ;-)


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 24 January 2012 21:58:34 UTC