- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 10 Jan 2013 14:12:08 -0800
- To: "www-style@w3.org" <www-style@w3.org>
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
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
Received on Thursday, 10 January 2013 22:12:40 UTC