[css-tables-3] Special weirdness of replaced vs. non-replaced percentage resolution

[fantasai]

@bfgeek wrote in #4638 (comment) :

So there is a super edge case within tables for WebKit/Blink/EdgeHTML which relies on this distinction, (and we believe it is required for webcompat).
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8045

Basically in the above example replaced elements resolve their values, differently to non-replaced. (I think it should be fine to keep this as a replaced vs. non-replaced distiction, rather than has-ar vs. no-ar.)

Tables spec needs to handle this. :/

[bfgeek]

Previous issue:
#4638

[FremyCompany]

Isn't that already defined in the spec?

3.10.2. Row layout (first pass)
[...]
For the purpose of calculating this height [=the minimum height of a row], descendants of table cells whose height depends on percentages of their parent cell' height (see section below) 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.

For table-cell descendants whose percentage height was ignored as a result of the above, a second layout pass of the table-cell content will happen once height distribution has concluded to attempt to properly take this sizing into account (see section below)

Or is this about something else which I'm missing?

[FremyCompany]

Ok, the current text only explained the result by chance, because 100% of 100px is 100px, and the image's natural height is also 100px... When the cell height has been specified to 50px, it becomes obvious that both algorithms diverge.

Further analysis brings up the fact that, in the case of replaced elements, both layout passes keep ignoring the actual cell height, and use the defined one instead if one is provided, irrespective of whether a distribution step has changed that height further down the road. That's definitely not a case currently written in the spec, I will need to add new text for it.

My understanding is that we need a new rule that goes like this:

In the case of replaced elements, percentage heights always resolve based on the height of their parent table-cell if that height was definite, and ignore the height ultimately attributed to the cell (this final height can only be taller than the definite height, so this never results in content overflow).