Skip to content

[css-tables] percentage resolution #474

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
gregwhitworth opened this issue Sep 13, 2016 · 11 comments
Open

[css-tables] percentage resolution #474

gregwhitworth opened this issue Sep 13, 2016 · 11 comments
Assignees
@dbaron
Labels
css-tables-3 Current Work

Comments

@gregwhitworth
Copy link
Contributor

Compat Issues: yes

Description:
Percentage sizes used on direct-children of a table-cell require a second layout pass to be accounted for.

During the first layout pass, they can be resolved to "auto" but it seems people rely on a webkit-behavior where height:100% resolves as 0px in the first layout pass if the box is overflow:scroll/auto. It doesn't work in Firefox, but the fix for Firefox is to set a default height on the cell, then the percentage resolved based on that height. Edge having none of the bugs, we have webcompat issues. We would like to settle on either having Chrome/Safari bug fixed or standardize it.

Proposed Option:
During first pass, percentages are resolved as auto, except if they are height-related and used on a scrollable box, in which case they resolve as 0px. Edge changes its behavior, as well as Firefox once it fix the other bug.

CSS 2.1 Option:
They resolve as auto in all cases. Chrome and Safari change their behavior.

Other options:
We move to Firefox behavior where percentages resolve based on the specified height of the cell during the first pass (but the webcompat of this change is unknown).

Testcases:
https://jsfiddle.net/vmfrLzke/1/

Browsers Passing Test:
Blink/Webkit Pass
Gecko passes if you utilize the bug mentioned above which is how web devs work around this issue
Edge fails
@gregwhitworth gregwhitworth added the css-tables-3 Current Work label Sep 13, 2016
@dbaron
Copy link
Member

dbaron commented Sep 19, 2016

I had some old testcases at http://dbaron.org/css/test/2006/percent-height-in-tables

@FremyCompany
Copy link
Contributor

This was discussed but not resolved by the CSSWG during TPAC2016, but no conclusion was reached yet.

@FremyCompany
Copy link
Contributor

Summary of the issue

<td><div style="height: 100%"></div></td>

I reviewed all of dbaron's test cases. they are 100% interoperable between Edge and Chrome.

They also match the proposed spec text and testcases.

Face to face recommendation

Resolve on proposed spec text:

  • During the first layout pass:
    • neither <table> nor <tr> nor <td> has height -> they behave as auto
    • else if overflow:scroll|auto -> they resolve to "0px" (webkit+gecko webcompat)
    • else -> they resolve to "auto"
  • During second pass:
    • neither <table> nor <tr> nor <td> has height -> they behave as auto
    • else they resolve based on row's final height

Examples

https://wptest.center/#/zez4x1 (Edge+Chrome)
https://wptest.center/#/d1e6b2 (Firefox+Chrome)

@gregwhitworth
Copy link
Contributor Author

Link to relevant spec text: https://drafts.csswg.org/css-tables-3/#row-layout

@mstensho
Copy link
Contributor

I'm working on a fix for https://bugs.chromium.org/p/chromium/issues/detail?id=964282 in LayoutNG (Blink's new layout engine), to match the old Blink layout engine. The patch is here: https://chromium-review.googlesource.com/c/chromium/src/+/1621166

The current wording in the spec seems to favor the WebKit/Blink behavior (well, almost).

For the purpose of calculating this height, descendants of table cells whose height depends on percentages of their parent cell' height are considered to have an auto height if they have overflow set to visible or hidden or if they are replaced elements, and a 0px height if they have not. Testcase !!Testcase

BTW: The two testcases there don't have a pass condition, so I don't know what's expected.

The interesting detail here is when the cell/table has auto height (which the spec doesn't cover). In that case it doesn't really make a lot of sense to resolve a percentage height block with overflow scroll/auto to 0. Or does it?

<!DOCTYPE html>
<p>There should be a green square below.</p>
<div style="display:table;">
  <div style="overflow:auto; height:100%; background:green;">
    <div style="width:100px; height:100px;"></div>
  </div>
</div>

@FremyCompany 's comment above, though, regarding an old F2F recommendation, seems to match exactly what Blink (the old engine) (and presumably WebKit) does (and my test should pass). Are we waiting for the spec to be edited?

@FremyCompany
Copy link
Contributor

@mstensho My understanding is that this case is covered by CSS 2, because in that specific case the computed value of the height on the div will be auto and not 100%.

<percentage>
 - Specifies a percentage height. 
 - The percentage is calculated with respect to 
       the height of the generated box's containing block. 
 - If the height of the containing block is not specified explicitly (i.e., it depends on content height), 
       and this element is not absolutely positioned, 
       the value computes to 'auto'.

~ https://drafts.csswg.org/css2/visudet.html#the-height-property

I can add a note referring to this in the spec if that would make things clearer.

@mstensho
Copy link
Contributor

@FremyCompany I think that would be helpful. Tables are quirky. It's not that obvious that a percentage-height child of an auto-height cell should NOT resolve to auto just because the table has a fixed height, for instance.

@FremyCompany
Copy link
Contributor

@mstensho I mean, technically the spec already covers this in the section just above, but I agree that it wouldn't hurt bringing this to attention right next to the relevant text:

It is appropriate to resolve percentage heights on direct children of a table-cell if the cell is considered to have its height specified explicitly or the child is absolutely positioned, see CSS 2.

For compat reasons, it is further clarified that a cell is considered to have its height specified explicitly if the computed height of the cell is a length, or if the computed height of its table-root ancestor is a length or percentage, regardless of whether that percentage does behave as auto or not.

~ https://drafts.csswg.org/css-tables-3/#computing-the-table-height

I will make the clarification, as well as another one still in the queue, and ask for a new publication at next F2F just so the TR version also gets the updates.

@mstensho
Copy link
Contributor

Sounds good. Thanks!

@FremyCompany
Copy link
Contributor

Ok, I performed some content reordering and restructuring around that section. Here's how things look like now:

I added a link in the section you quoted:

image

which links to:

image

which is now its own section rather than an advisement in another section.

@mstensho
Does that sound good to you?

@mstensho
Copy link
Contributor

@FremyCompany Looks good to me. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dbaron dbaron

Labels
css-tables-3 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dbaron @FremyCompany @gregwhitworth @astearns @mstensho