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

Status: RESOLVED FIXED

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

Description

[Steve Ward]

Attachment: 2 tables showing that using percent in calc() does not work

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%.

Comment 1

[Steve Ward]

This is related to #776443.

Comment 2

[sjw]

Workaround: Use 100vw instead of 100%.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I would be very disinclined to do this unless there is an actual specification for the behavior...

Comment 4

[Tomek Wytrebowicz]

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%`

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 7

[Tomek Wytrebowicz]

Thanks for the answer.


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

Comment 9

[Gérard Talbot]

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.

Comment 10

[Gérard Talbot]

I created bug 1503165 a few min. ago.

Comment 11

[Gérard Talbot]

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

[Gérard Talbot]

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

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I got bitten by this and took a look.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 957915 - Handle calc(%) on tables.

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.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

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

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d50d152c74c7
Handle calc(%) on tables. r=mats

Comment 17

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/d50d152c74c7

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

WPT PR at https://github.com/web-platform-tests/wpt/pull/14930