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

Re: [CSS21] Overconstrained fixed table layout

From: Gérard Talbot <www-style@gtalbot.org>
Date: Thu, 10 Jan 2013 19:13:10 -0500
Message-ID: <b3cd0040a7b38f9f1235d12343b03607.squirrel@ed-sh-cp3.entirelydigital.com>
To: "fantasai" <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>

Le Jeu 10 janvier 2013 17:12, fantasai a écrit :
> Gérard pointed out to me that the spec for fixed table layout
> seems to have some problems in the area of overconstrained
> fixed table layout. The relevant test cases are:
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-025.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-026.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-027.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-028.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-029.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-030.htm
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-031.htm

2 other tests:


and the width of the cell in first column is -16px, that is minus 16px.

> Specifically, the issue is how padding and borders factor into
> the initial column width calculations. The algorithm says that
> you only account for the width of cells with specified widths.
>    http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout
> We don't have interop on this.
> The problems I see so far are:
>    * A column element's 'width' property sets the column's width.
>      That's fine. But if it's width is 'auto', you take the 'width'
>      of the first cell. But the 'width' typically does not include
>      the cell's borders/padding -- shouldn't this be 'width' plus
>      horizontal borders/padding?
>    * When calculating a column width from the cell, the cell's
>      parameters are ignored when its width is 'auto'. Shouldn't
>      borders/padding factor into the table's width; and shouldn't
>      they be subtracted from the remaining width before distributing
>      to 'auto' columns?
>    * Fixed table layout can result in table cells with negative
>      widths. It's not specified what that means in terms of layout,
>      since layout generally assumes that containing blocks are
>      non-negative.
> ~fantasai

"(...) 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. (...) we should
probably just make it explicit what it means for a cell to 'determine' a
column width." Boris Zbarsky

coming from http://lists.w3.org/Archives/Public/www-style/2011Apr/0743.html

CSS 2.1 Test suite RC6, March 23rd 2011

Contributions to CSS 2.1 test suite

Web authors' contributions to CSS 2.1 test suite
Received on Friday, 11 January 2013 00:13:45 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:23 UTC