Closed Bug 652941 Opened 11 years ago Closed 11 years ago
Incorrect cell size with table-layout:fixed and col width when cellpadding is nonzero
When using a table with table-layout:fixed and specifying the size of cells via <col width=100>, cells have wrong sizes. IE 6 and Chrome 10 display the table as expected.
It looks like the width of the cell ends up being width of col minus the cellpadding. That is, the width of the column set by the col is the width specified on the col, while the width of the column set by the _cell_ is the width of the cell plus its left and right padding. CSS 2.1 section 220.127.116.11 says this: A column element with a value other than 'auto' for the 'width' property sets the width for that column. Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns. I have to assume that "sets" versus "determines" there is purposeful, but who knows.... In any case, the text in 17.5 is quite clear: The edges of the rows, columns, row groups and column groups in the collapsing borders model coincide with the hypothetical grid lines on which the borders of the cells are centered. Which means that the width of a column means the width of the padding-box of the cells, plus half the border width. In other words, as far as I can tell our layout is correct and Chrome and IE 6 are buggy.
Summary: Incorrect cell size with table-layout:fixed and col width → Incorrect cell size with table-layout:fixed and col width when cellpadding is nonzero
Opera renders this the same way we do. IE9 seems to have the same rendering as IE6. WebKit has had a bug on this reported since 2007 or so: https://bugs.webkit.org/show_bug.cgi?id=13339
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
I tried to figure out how to report a bug to Microsoft and gave up.
Thanks for clarification. What's really not intuitive is that a cell size is calculated differently: In the case <td width=100>, 100 does not include padding. In the case of <col width=100>, it should include padding. So if a cellpadding is 4px then you have to use <col width=108>. Sigh.
Oh, and for this testcase the relevant thing in 17.5 is the separated border model, which says: In the separated borders model, the edges coincide with the border edges of cells.
Yes, I agree that this does mean that you have to know what your cell paddings are if you want to set cells to a particular width by setting column widths....
I have examined attachment 528419 [details] in Firefox 7.0.1 and I do not see an error or spec violation for the 2nd (at bottom) table. <table summary="" border="0" cellpadding="4" cellspacing="0" style="width:500px; table-layout:fixed"> <colgroup> <col width="100" /> <col width="384" /> </colgroup> <tbody> <tr> <td style="background-color:red">requested 100<br>actual 95.3</td><td style="background-color:yellow">requested 384<br>actual 388.7</td> </tr> </tbody> </table> The width of the table as set is greater than the sum of columns. In which case, the spec states: " The width of the table is then the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders). If the table is wider than the columns, the extra space should be distributed over the columns. " So, 500 - (100 + 384) = 16. Therefore, 16px will be distributed in both columns. When I examine the computed width of the 2 columns of 2nd table in attachment 528419 [details] in Firefox's DOM inspector, it returns 103 and 397. Unfortunately, the spec does not indicate how the extra space should be distributed over the columns: it does not say "evenly" or "equally". So, 103 and 397 are compliant values. Each cell has a total of 8px of padding. Therefore, the first cell will/should be/should have a 103px - 8px width: 95px. The 2nd cell should have a 397px - 8px width: 389px. DOM inspector returns 95.3px and 388.7px. The origin of the fractional parts is unknown to me. But as far as I can say, the mathematics are correct and the values returned are predictable. Opera 11.51 returns 95px for first cell computed width and 389px for the 2nd cell computed width of 2nd table. One final remark: Firefox's DOM inspector is the only webpage layout debugging/inspecting tool that reports the computed width of a column, regardless if it was set to auto or not. regards, Gérard
The spec may not indicate how the extra space should be distributed over the columns but, so far, 3 browsers (Firefox 7.0.1, Opera 11.51, IE8) distribute such extra space in the same way. In the testcase, the ratio (proportion) of the extra space that the first column gets is given by 16 * (100/484) = 3.30px and the second column gets: 16 * (384/484) = 12.69px This explains, I guess, the origin of fractional parts in Firefox 7.0.1; the logic of distributing extra space among columns is the same in all 3 browsers. I examined computed width of the 2 table cells of 2nd table in attachment 528419 [details] in IE8 and, although the Developer Tools/Layout is confused and not reporting exact and correct values (for padding, width), the rendered table as laid out is compliant with the spec. IE8, in Developer Tools/Layout, the width of the table cells is its offsetWidth, not its computed width. regards, Gérard
Distributing the extra space proportionally to column width (sorta; things get complicated with colspans) is in fact a requirement for web compat... that's why all the browsers involved do that.
You need to log in before you can comment on or make changes to this bug.