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

RESOLVED FIXED in Firefox 66

Status

()

defect
P3
normal
RESOLVED FIXED
6 years ago
5 months ago

People

(Reporter: planet36, Assigned: emilio)

Tracking

({testcase})

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)

Details

Attachments

(2 attachments)

Reporter

Description

6 years ago
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%.
Reporter

Comment 1

6 years ago
This is related to #776443.

Comment 2

6 years ago
Workaround: Use 100vw instead of 100%.

Updated

6 years ago
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...

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

Comment 4

3 years ago
I got a bit different example for the issue given in the title: http://jsbin.com/juqafi/1/edit?html,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:
https://hg.mozilla.org/mozilla-central/file/69ec3dc408a2/layout/tables/BasicTableLayoutStrategy.cpp#l144
(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

Comment 7

3 years ago
Thanks for the answer.


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

Updated

8 months ago
Duplicate of this bug: 1297576

Comment 9

8 months ago
David,

The 2nd sub-test of your test

http://test.csswg.org/suites/css-values-3_dev/nightly-unstable/html/calc-width-table-auto-1.htm

predicts one particular layout 

http://test.csswg.org/suites/css-values-3_dev/nightly-unstable/html/reference/calc-width-table-auto-1-ref.htm

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 

http://www.gtalbot.org/BugzillaSection/Bug957915-td-width-calc-percent-table-auto.html

illustrates the issue.

Updated

8 months ago
Keywords: testcase

Comment 10

8 months ago
I created bug 1503165 a few min. ago.

Comment 11

7 months ago
Firefox 60.3.0 ESR and Firefox 65.0a1 buildID=20181127220131 fail this test:

http://www.gtalbot.org/BrowserBugsSection/CSS3Values/calc-width-td-009.html

Comment 12

7 months ago
Test:
http://www.gtalbot.org/BrowserBugsSection/CSS3Values/calc-width-td-percent-021.html

Reference:
http://www.gtalbot.org/BrowserBugsSection/CSS3Values/calc-width-td-percent-021-ref.html

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:
https://trac.webkit.org/browser/webkit/trunk/LayoutTests/css3/calc/table-empty-cells.html
Assignee

Comment 13

6 months ago
I got bitten by this and took a look.
Blocks: 1517511
Priority: P5 → P3
Assignee

Updated

6 months ago
Assignee: nobody → emilio
Assignee

Comment 14

6 months ago
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 https://github.com/w3c/csswg-drafts/issues/3482 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.
Assignee

Comment 15

6 months ago
Note that this keeps treating stuff with both lengths and percentages as auto.

Comment 17

5 months ago
bugherder
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.