WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
74955
WebKit adds vertical paddings and borders to the fixed width of CSS tables
https://bugs.webkit.org/show_bug.cgi?id=74955
Summary
WebKit adds vertical paddings and borders to the fixed width of CSS tables
Max Vujovic
Reported
2011-12-20 14:07:26 PST
Created
attachment 120078
[details]
Reproduction In the attached reproduction, the CSS table has a width style of 100px and a padding-top style of 400px. In WebKit, the table's computed width is 500px (100px+400px), but it should be 100px. Firefox and Opera produce the correct results.
Attachments
Reproduction
(897 bytes, text/html)
2011-12-20 14:07 PST
,
Max Vujovic
no flags
Details
Patch
(6.28 KB, patch)
2011-12-20 14:28 PST
,
Max Vujovic
no flags
Details
Formatted Diff
Diff
Patch
(15.79 KB, patch)
2012-01-04 10:22 PST
,
Max Vujovic
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Max Vujovic
Comment 1
2011-12-20 14:28:05 PST
Created
attachment 120087
[details]
Patch I uploaded patch that fixes the issue and makes WebKit's behavior match Firefox's and Opera's. The problem was that the width calculation for CSS tables was using borderBefore(), paddingBefore(), borderAfter(), and paddingAfter(), which actually correspond to the vertical borders and paddings. I changed it to use borderStart(), paddingStart(), borderEnd(), and paddingEnd(), which correspond to the horizontal borders and paddings.
Eric Seidel (no email)
Comment 2
2011-12-21 12:30:32 PST
This seems reasonable to me, but really Beth/hyatt are more familiar with this code.
Max Vujovic
Comment 3
2011-12-21 13:19:09 PST
Thanks for looking at it, Eric. I was planning to ping Julien for a review when he comes on IRC since he changed some code around there recently. Of course, Beth or Hyatt are welcome to review if they have time.
Julien Chaffraix
Comment 4
2011-12-21 14:29:25 PST
Comment on
attachment 120087
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=120087&action=review
Good catch! Some comments but the change is very fine.
> LayoutTests/fast/table/script-tests/css-table-width.js:3 > +description( > +"This test checks that the width style is applied correctly to CSS tables with respect to table paddings and borders." > +);
You can put that on one line.
> LayoutTests/fast/table/script-tests/css-table-width.js:40 > +shouldEvaluateTo("computeCSSTableWidth('width: 200px; border-style: solid; border-width: 10px 2px 30px 4px; padding: 50px 6px 70px 8px;')", 200+2+4+6+8); > +shouldEvaluateTo("computeCSSTableWidth('width: 200px; border-style: solid; border-width: 10px 2px 30px 4px; padding: 50px 6px 70px 8px; border-collapse: collapse;')", 200 + (2+4)/2);
I would love to see some examples with a vertical writing mode (like 'writing-mode: vertical-rl') and some values of 'text-orientation' / 'direction' as this test feels not sufficient. Also a vertical writing mode would have shown the issue pretty easily (just put some padding in the inline base direction but not in the block flow direction).
> Source/WebCore/rendering/RenderTable.cpp:233 > + LayoutUnit bordersAndPadding = 0;
I am not too fond of the naming. You don't include the paddings if you are on a collapsing border CSS table. I couldn't find anything better (my take was bordersAndPaddingsOnNonCollapsingBordersTable which is too long). The variable name should at least be bordersAndPaddings for consistency.
Max Vujovic
Comment 5
2011-12-21 15:23:55 PST
Thanks for the review, Julien!
> > LayoutTests/fast/table/script-tests/css-table-width.js:3 > > +description( > > +"This test checks that the width style is applied correctly to CSS tables with respect to table paddings and borders." > > +); > > You can put that on one line.
Sounds good.
> I would love to see some examples with a vertical writing mode (like 'writing-mode: vertical-rl') and some values of 'text-orientation' / 'direction' as this test feels not sufficient. Also a vertical writing mode would have shown the issue pretty easily (just put some padding in the inline base direction but not in the block flow direction).
Very good idea- I'll craft some more tests and reupload a patch.
> > Source/WebCore/rendering/RenderTable.cpp:233 > > + LayoutUnit bordersAndPadding = 0; > > I am not too fond of the naming. You don't include the paddings if you are on a collapsing border CSS table. > > I couldn't find anything better (my take was bordersAndPaddingsOnNonCollapsingBordersTable which is too long). The variable name should at least be bordersAndPaddings for consistency.
Good point. Both "borders" and "bordersAndPaddings" aren't entirely right, but "borders" sounds better. I'll change it back to "borders" :)
Max Vujovic
Comment 6
2012-01-04 10:22:32 PST
Created
attachment 121122
[details]
Patch I've updated the patch with the changes from the previous comment. I've added more test cases with different combinations of writing-mode, direction, and text-orientation.
Julien Chaffraix
Comment 7
2012-01-04 14:07:06 PST
Comment on
attachment 121122
[details]
Patch The cr-linux EWS seems to be cycling and failing on some other issue. The previous change properly passed the bot so it should be fine to land this one. r = me
WebKit Review Bot
Comment 8
2012-01-05 04:23:58 PST
Comment on
attachment 121122
[details]
Patch Clearing flags on attachment: 121122 Committed
r104140
: <
http://trac.webkit.org/changeset/104140
>
WebKit Review Bot
Comment 9
2012-01-05 04:24:03 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug