- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 23 Jan 2012 23:40:39 +0100
- 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 UTC