The latest (April 11th 2006) release of CSS 2.1 is a bit more explicit and easier to read: "'padding-top', 'padding-right', 'padding-bottom', 'padding-left' Value: <padding-width> | inherit Initial: 0 Applies to: all elements except table-row-group, table-header-group, table-footer-group, table-row, table-column-group and table-column" CSS 2.1, Section 8.4 Padding http://www.w3.org/TR/2006/WD-CSS21-20060411/box.html#padding-properties "The five properties related to padding ('padding', 'padding-top', 'padding-right', 'padding-bottom', and 'padding-left') now say that they don't apply to table rows, row groups, header groups, footer groups, columns, and column groups." CSS 2.1, Section C.3.10 http://www.w3.org/TR/2006/WD-CSS21-20060411/changes.html#q36

Confirmed the third result isn't correct, both Opera and Firefox render it correctly. Reporter, would it be possible to attach the testcase to the bug? Thx!

Created attachment 9313 [details] reduced test case In case the reporter does not feel comfortable adding his test case, I am attaching a reduction of just the table with the issue.

> Reporter, would it be possible to attach the testcase to the bug? > In case the reporter does not feel comfortable adding his test case, I am > attaching a reduction of just the table with the issue. Sorry, I did not get this bugmail due to various reasons, one being my webhosting company going through its own difficulties, overloads. The URL provided in this bugfile form is the original testcase: I feel confortable with whatever you do to fix this bug :) . There is a pseudo-rule right under the table so that measurements or verifications can be done easily and graphically. Thank you both (Joost and Sam) for confirming this bug and for your interest Gérard

Created attachment 10498 [details] Patch.

This change is probably worth explaining (I enhanced the comment a bit in my tree). When computing the minimum and maximum preferred widths for cells, we have a method called styleOrColWidth that attempts to snag the width from the cell, and if not set there, it uses the column. The problem arises when fixed widths are specified on the column. For percentage widths on cells vs. columns there is no difference, since a box-sizing rule of border-box is effectively what is assumed in all cases. For fixed widths though the behavior is different. A fixed width column is *still* applied to the border box of the cell. Therefore we need to subtract out the border and padding of the cell from the width returned. It will then get added back in later. (This does mean we'll fail degenerate cases where the border/padding exceed the column width, but the table code is full of that problem, and I'm not overly concerned about it.)

Actually it occurred to me that even the degenerate case of too-small column widths will still behave correctly, so everything's all good here.

Comment on attachment 10498 [details] Patch. r=me

Fixed by hyatt in r16315, test in r16316.

Thank you for fixing this bug! :) Marking as VERIFIED