Closed
Bug 776443
Opened 13 years ago
Closed 13 years ago
calc() doesn't work on table cells or rows
Categories
(Core :: Layout: Tables, defect)
Core
Layout: Tables
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: moz, Assigned: bzbarsky)
References
Details
(Keywords: dev-doc-needed, testcase)
Attachments
(3 files, 2 obsolete files)
568 bytes,
text/html
|
Details | |
10.28 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
13.18 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
calc() doesn't work on table cells.
Testcase works partly in IE and WebKit (width part fails).
![]() |
Assignee | |
Comment 1•13 years ago
|
||
What the spec actually says seems to be this:
Given the complexities of width and height calculations on table cells and table
elements, math expressions involving percentages for widths and heights on table
columns, table column groups, table rows, table row groups, and table cells in
both auto and fixed layout tables MAY be treated as if ‘auto’ had been specified.
so the width behavior you see is perfectly fine per spec.
That said, we actually do this for _any_ calc expression, not just ones involving percentages.....
Component: Style System (CSS) → Layout: Tables
![]() |
Assignee | |
Comment 2•13 years ago
|
||
There are two places in the reflow state that treat calc() as auto for tables, and also various places in the table code itself.
David, how do you feel about making calc() not involving percentages just work here?
(In reply to Boris Zbarsky (:bz) from comment #2)
> There are two places in the reflow state that treat calc() as auto for
> tables, and also various places in the table code itself.
>
> David, how do you feel about making calc() not involving percentages just
> work here?
That's fine; probably what I should have done originally.
And nsStyleCoord::ConvertsToLength() is a convenient helper for this type of check.
![]() |
Assignee | |
Comment 6•13 years ago
|
||
Any ideas on how to test some of those codepaths are much appreciated!
Attachment #645026 -
Flags: review?(dbaron)
![]() |
Assignee | |
Comment 7•13 years ago
|
||
Attachment #645028 -
Flags: review?(dbaron)
![]() |
Assignee | |
Updated•13 years ago
|
Attachment #645026 -
Attachment is obsolete: true
Attachment #645026 -
Flags: review?(dbaron)
![]() |
Assignee | |
Comment 8•13 years ago
|
||
Attachment #645030 -
Flags: review?(dbaron)
![]() |
Assignee | |
Updated•13 years ago
|
Attachment #645028 -
Attachment is obsolete: true
Attachment #645028 -
Flags: review?(dbaron)
![]() |
Assignee | |
Comment 9•13 years ago
|
||
Attachment #645040 -
Flags: review?(dbaron)
![]() |
Assignee | |
Updated•13 years ago
|
Assignee: nobody → bzbarsky
Whiteboard: [need review]
![]() |
Assignee | |
Updated•13 years ago
|
Summary: calc() doesn't work on table cells → calc() doesn't work on table cells or rows
Comment on attachment 645030 [details] [diff] [review]
part 1. Support percent-less calc for internal table element heights.
r=dbaron
Attachment #645030 -
Flags: review?(dbaron) → review+
Comment on attachment 645040 [details] [diff] [review]
part 2. Support percent-less calc for internal table element widths.
It would be good to also change nsLayoutUtils::IntrinsicForContainer to check !styleWidth.ConvertsToLength instead of checking styleWidth.GetUnit() != eStyleUnit_Coord for the codepath that avoids doing intrinsic width computation because we know GetAbsoluteCoord(styleWidth, w) is going to succeed. (Though the reason it's skipping the intrinsic width computation should probably also be explained in the comment.) (I noticed this because of the codepaths leading from FixedTableLayoutStrategy to IntrinsicForContainer that you're now going to call in those cases because of this patch.)
r=dbaron with that
Attachment #645040 -
Flags: review?(dbaron) → review+
![]() |
Assignee | |
Comment 13•13 years ago
|
||
Done, and:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e02a02fd1208
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a8b11ae0f4b
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla20
Comment 14•13 years ago
|
||
Sorry, something in your push turned the mochitests orange. I had to back the entire thing out.
https://hg.mozilla.org/integration/mozilla-inbound/rev/461a2225b7ba
Target Milestone: mozilla20 → ---
![]() |
Assignee | |
Comment 15•13 years ago
|
||
The orange was from bug 812392. But this push did cause reftest failures. Fixed those, and repushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7f0893a44057
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf8196bc19b4
Target Milestone: --- → mozilla20
Comment 16•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/7f0893a44057
https://hg.mozilla.org/mozilla-central/rev/cf8196bc19b4
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•