- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 Nov 2011 11:57:56 -0800
- To: www-style@w3.org
On 11/22/2011 12:29 PM, fantasai wrote: > Gérard Talbot recently pointed me at this section, which seems to have an error in it: > > http://www.w3.org/TR/CSS21/tables.html#height-layout > # 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. A 'height' value of 'auto' for a 'table-row' means > # the row height used for layout is MIN. MIN depends on cell box heights and cell > # box alignment (much like the calculation of a line box height). > > Read literally, it says that 'height' on table cells is ignored unless 'height' on > the table row is non-auto. That seems wrong. There's another issue on this sentence, which is whether 'height' on the table cell is added to its border+padding and then applied as a minimum on the row, or whether it is directly applied to the row box. It appears we do not have interop on this. Gérard has written some tests to demonstrate: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/height-cell-bc-collapse.html http://www.gtalbot.org/BrowserBugsSection/css21testsuite/height-cell-bc-separate.html He reports that Firefox 7+, Opera 11.52 and Konqueror 4.7.3 render no green in height-cell-bc-separate (i.e. they apply the 'height' directly to the row box) whereas IE8, IE9, Chrome 15.0.874.121 and Safari 5.1.1 render a green square with thick black borders (i.e. they add the cell's border and padding to the 'height' to arrive at the minimum height it contributes to the row). ~fantasai
Received on Tuesday, 29 November 2011 19:58:34 UTC