652941 - Incorrect cell size with table-layout:fixed and col width when cellpadding is nonzero

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Marius Strumyla]

Attachment: Testcase

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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 17.5.2.1 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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

I tried to figure out how to report a bug to Microsoft and gave up.

Comment 4

[Marius Strumyla]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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....

Comment 7

[Gérard Talbot]

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

Comment 8

[Gérard Talbot]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.