Re: [CSS21] Issues with Ch.17 Tables

Le Lun 23 janvier 2012 17: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.)


Yes. Agreed. Such situation should be clarified.



> 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 am for thorough consistency in vocabulary and terminology used in the
spec. This also helps beginners, everyone's understanding, translators,
reduce interpretation and potential source of confusion, etc.


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

Like Simon says, this is a non-issue. Although... Safari 5, Chrome 16 and
Konqueror 4.8 have a bug on vertical border-spacing when adjacent cells
are from 2 contiguous table-row-groups:



http://www.gtalbot.org/BrowserBugsSection/css21testsuite/dynamic-border-spacing.html

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/separated-border-model-007.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/separated-border-model-008.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/separated-border-model-009.htm

More info:

http://lists.w3.org/Archives/Public/public-css-testsuite/2011Feb/0047.html


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

Yes. "the border between cells i and i + 1" must mean the resulting
maximum of all relevant individual border widths between the 2 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?


Yes. This needs to be clarified in the spec.


"
(...) the column width is set to the width of the cell plus its left
padding plus its right padding plus half its left border plus half its
right border in the collapsing border model, and the same but using full
border widths in the separated border model.
"
[css21] Section 17.5.2.1 should be clarified
coming from
http://lists.w3.org/Archives/Public/www-style/2011Apr/0743.html


Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Tuesday, 24 January 2012 20:35:50 UTC