Closed Bug 957915 Opened 11 years ago Closed 5 years ago

Support calc() with percentages for table cell and column widths


(Core :: CSS Parsing and Computation, defect, P3)




Tracking Status
firefox66 --- fixed


(Reporter: planet36, Assigned: emilio)



(Keywords: testcase)


(2 files)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

I tried to make a table with 7 columns of equal width using this style:
th {width: calc(100%/7);}

Actual results:

The width of the columns was "auto".

Expected results:

The width of the columns should have been about 14%.
This is related to #776443.
Workaround: Use 100vw instead of 100%.
Component: Untriaged → CSS Parsing and Computation
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All
Version: 26 Branch → Trunk
I would be very disinclined to do this unless there is an actual specification for the behavior...
Ever confirmed: true
Priority: -- → P5
I got a bit different example for the issue given in the title:,css,output
`calc(10%+20%)` fails. Even though spec says
> Given the complexities of width and height calculations ... math expressions involving percentages for widths ... on table columns ... MAY be treated as if auto had been specified.

But it also says:
> The computed value of a `calc(`) expression is the expression with all components computed, with all multiplication/division subexpressions resolved, and with all addition/subtraction subexpressions resolved where both sides are the same type.
And also gives an example "e.g. `calc(100% - 100% + 1em)` resolves to `calc(0% + 1em)`".

Therefore, I would say that specifications actually guide us to resolve `calc(10% + 20%)` to `calc(30%)`. Such value does not seem to fit "the complexities of width and height calculations", as it fairly resolves, directly, to just `30%`
The basic problem here is that the way percentage widths work on table cells doesn't really deal well with a given cell having components that come from both a percentage and a length, since the table width algorithm assigns each *column* a single width that is either a percentage or a length or auto, and the percentages and lengths behave in substantively different ways.
The relevant code starts here:
(that's a link that should always point to the code as it is today).
Summary: Support percent calc for internal table element widths → Support calc() with percentages for table cell and column widths
Thanks for the answer.

Just to note, in my example, I'm assigning width to a column (`<col>`) not to a cell (`<td>`)

The 2nd sub-test of your test

predicts one particular layout

for the cell with 'width: calc(50%)', which Chromium 69 and Epiphany 3.22+ do not comply with. If the expected result for a cell with 'width: 50%' is not specified by the spec, then why would the rendered layout differ when using 'width: calc(50%)'?

This test

illustrates the issue.
Keywords: testcase
I created bug 1503165 a few min. ago.
Firefox 60.3.0 ESR and Firefox 65.0a1 buildID=20181127220131 fail this test:


Firefox 65.0a1 buildID=20181128100125 fails all 13 sub-tests.

Chromium 70.0.3538.110 and Epiphany 3.22.7 (Webkit 2.18.6) pass all 13 sub-tests.

In the 13 sub-tests, the <table>s' CSS width is defined and set to '100%'.

Original test:
I got bitten by this and took a look.
Blocks: 1517511
Priority: P5 → P3
Assignee: nobody → emilio
This patch makes us handle calc with percentages when we can convert to
percentages the same way we handle plain percentages in table layout.

We still treat length + percentage as auto (this matches Blink / WebKit as
well). There's one case we differ with Blink / WebKit, which is calc(% + 0px),
which they'd treat as auto instead of a percentage.

I think this is a bug on them (or at least worth some spec clarification). I
filed for that.

In practice what that'd means for us if the WG decides that Blink / WebKit is
right in that case is that we'd need to keep track of whether the calc()
specifies lengths, and return false from ConvertsToPercent if so.

In any case, nothing that would massively change this patch, and I think enough
of an edge case that is not worth blocking on the CSSWG decision here. Though I
could be convinced otherwise of course.
Note that this keeps treating stuff with both lengths and percentages as auto.
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.