Re: [csswg-drafts] [css-tables] percentage resolution (#474)

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?

-- 
GitHub Notification of comment by mstensho
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/474#issuecomment-494283274 using your GitHub account

Received on Tuesday, 21 May 2019 07:58:47 UTC