|Summary:||Padding must not apply to column|
|Product:||WebKit||Reporter:||Gérard Talbot <browserbugs2>|
|OS:||OS X 10.4|
Description Gérard Talbot 2006-04-01 17:35:25 PST
Reference: "'padding-top', 'padding-right', 'padding-bottom', 'padding-left', 'padding' Applies to: all elements except elements with table display types other than table, inline-table, and table-cell" coming from CSS 2.1, Section 8.4 Padding http://www.w3.org/TR/CSS21/box.html#padding-properties Reference: "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." coming from CSS 2.1, Section C.3.10 http://www.w3.org/TR/CSS21/changes.html#q36 Steps to reproduce: Load the testcase at provided URL (I tried with Safari 2.02 (416.13)). Expected results: Each of the 3 tables must measure exactly 300px. I searched for duplicate bugfile and couldn't find one.
Comment 1 Gérard Talbot 2006-07-07 06:21:07 PDT
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
Comment 2 Joost de Valk (AlthA) 2006-07-09 13:36:50 PDT
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!
Comment 3 Sam Weinig 2006-07-09 15:10:09 PDT
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.
Comment 4 Gérard Talbot 2006-07-18 20:15:25 PDT
> 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
Comment 6 Dave Hyatt 2006-09-11 00:37:06 PDT
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.)
Comment 7 Dave Hyatt 2006-09-11 20:40:10 PDT
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 8 Adam Roben (:aroben) 2006-09-11 21:27:44 PDT
Comment on attachment 10498 [details] Patch. r=me
Comment 9 David Kilzer (:ddkilzer) 2006-09-12 08:06:11 PDT
Comment 10 Gérard Talbot 2008-03-21 09:01:43 PDT
Thank you for fixing this bug! :) Marking as VERIFIED