Percentage heights of elements within a table cell are not considered when their display value generates a block element box but is not table or inline-table.

Though if the value is changed to one of those it is considered. Furthermore, changing it back to the previous value lets the layout still consider the percentage height.

According to the CSS Tables 3 spec. it seems that percentage heights on the descendant elements within a table cell should always be considered, though neither Blink nor EdgeHTML support that at the moment.

This bug was initially mentioned in a Discourse thread.

See the attached test case showing the bug. (Clicking the button toggles the display property between block and table.)

Sebastian

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

According to the CSS Tables 3 spec. it seems that percentage heights on the descendant elements within a table cell should always be considered, though neither Blink nor EdgeHTML support that at the moment.

I wouldn't pay too much attention to that spec-text - table layout is largely unspecified, and I believe the spec text that exists (and that gets into enough detail for this scenario) is meant to try to harmonize/rationalize/describe the existing web engines' table layout. So, if the spec says something here that disagrees with Gecko/Blink/EdgeHTML (and I assume also WebKit), then the spec text is probably wrong rather than the engines.

Having said that: it does seem that we have an incremental layout bug here. Our initial layout (blue area short) disagrees with the layout after you click the button twice (blue area tall), and then if I open devtools, we go back to the initial layout (blue area short). So this is definitely an internal-consistency bug.

(Bug 1386982 suggests that our initial layout -- with the blue area short -- is correct, at least as of the spec discussions around the time when that bug was filed. Marking as depending on that bug.)