Closed Bug 2886 Opened 26 years ago Closed 25 years ago

{css1} uneven top/bottom padding/border mis-places cell contents

Categories

(Core :: Layout: Tables, defect, P2)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cmanske, Assigned: karnaze)

References

Details

(Keywords: css1, Whiteboard: fix attached [TESTCASE])

Attachments

(3 files)

tests; padding property inside table cell
(deleted), text/html
Details
proposed fix
(deleted), text/html
Details
proposed fix, correct MIME type...
(deleted), patch
Details | Diff | Splinter Review
Padding value is always 0. I'm not sure if this is a bug in tables or in CSS code, so please redirect if this isn't in table code.
Status: NEW → ASSIGNED
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Target Milestone: M6
<html><body> Moving to M6. Here is the test case. <table border=1> <tr><td style="padding:10px;">FOO</td></tr> </table> </body></html>
Moving to M8
Padding appears (to me) to work in table cells. Attaching a test case with a few variations in the way the padding-* properties are set. The only problem (if it is one) is in the padding-top and padding-bottom, which it appears that these padding values are "split" between top and bottom when inside a TD; is this correct behaviour? -- see cases 2), 5), 6) and the misc) examples at the bottom.
Summary: CSS padding property ignored in table cells → Problems with top and bottom padding and border in table cells
Changing bug title from "CSS padding property ignored in table cells" to "Problems with top and bottom padding and border in table cells". I see the top/bottom padding problem in the demos, but the other padding things are working fine. However, there's a similar bug I thought I reported but couldn't find having to do with border. In the table in: http://www.fas.harvard.edu/~dbaron/css/test/results There is a border on one row about ten rows from the bottom of the table. The numbers in that row show the same problem here - they are centered in the table including the border. I think this is a bug in the implementation of vertical-align on table cells. I should write a test for vertical-align on table cells to make sure there aren't other bugs to fix when you fix this one.
Summary: Problems with top and bottom padding and border in table cells → vertical alignment problems with top and bottom padding and border in table cells
I even had a simplified (i.e., cut down, but not really simplified) test case for the bug I never submitted at: http://www.fas.harvard.edu/~dbaron/tests/nglayout/tableprob (I probably forgot to fill out the component and didn't notice the error.)
*** Bug 6282 has been marked as a duplicate of this bug. ***
was the version of that test case in bug 6282. (Let's see if bugzilla makes that a link...). It's the same as the URL I gave (roughly, anyway).
Summary: vertical alignment problems with top and bottom padding and border in table cells → {css1} top and bottom padding on cells is wrongly distributed
[TESTCASE] Attachement 300: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=300 ...is a good minimal test case. Top and bottom CSS padding is being distributed equally above and below cells.
Summary: {css1} top and bottom padding on cells is wrongly distributed → {css1} uneven top/bottom padding/border mis-places cell contents
Ian changed title from "vertical alignment problems with top and bottom padding and border in table cells" to "{css1} top and bottom padding on cells is wrongly distributed", which doesn't mention that the problems are with border. Retitling bug to "{css1} uneven top/bottom padding/border mis-places cell contents". http://bugzilla.mozilla.org/showattachment.cgi?attach_id=160 is another test case for this bug, with a border problem. It might be worth testing if this bug only occurs on some values of vertical-align.
Moving to M9.
Whiteboard: [TESTCASE]
Attached file proposed fix (deleted) —
Whiteboard: [TESTCASE] → fix attached [TESTCASE]
Sorry about the first attachment - I'm in the habit of hitting text/html. The above patch fixes the bug for vertical-align: middle, and also makes vertical-align: baseline act like vertical-align: top, rather than ignoring top padding and border as it used to. vertical-align: baseline still needs to be (re-?)implemented.
*** Bug 7976 has been marked as a duplicate of this bug. ***
*** Bug 9067 has been marked as a duplicate of this bug. ***
I made bug 10207 for vertical-align: baseline not working for table cells.
Target Milestone: M9 → M11
Moving to M11
I'll clarify what the patch does in the hopes that that will speed up its adoption. It changes only two lines (plus adds a few comments). The first one-line change comments out a break statement so that vertical-align: baseline is, for now, treated like vertical-align: top, rather than "vertical-align: top; padding-top: 0". Previously, the top padding was being ignored since there was no code written for the baseline case. (Full support for the baseline value is left to bug 10207.) This fixes: * bug 7976 * The left column in bug 6282 * probably what the original reporter of this bug was seeing The second one-line change fixes the computation of position for vertical-align: middle. It was not accounting for the padding when centering the cell within the row (in the language of the spec, this is increasing the padding). That is, it was centering the content edge of the cell instead of the padding edge. This fixes: * attachment 300 [details] (on this bug) * all but the left column in bug 6282 * bug 9067
David, thanks for the patch. I added it and the 1st attachment is now correct. I'm not sure what else needs to be done for this bug.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Nothing else needs to be done. Remaining issues are in bug 10207. Marking RESOLVED-FIXED.
Status: RESOLVED → VERIFIED
Using 9/16 Apprunner and 6/24 testcase, verified bug fixed.
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: