- From: Gérard Talbot <www-style@gtalbot.org>
- Date: Thu, 10 Jan 2013 19:13:10 -0500
- 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: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/border-spacing-percentage-cell-001.html http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-003e08.htm 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 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 Friday, 11 January 2013 00:13:45 UTC