- 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