359481 - (table-height-rewrite) redesign percentage height handling and height distribution in tables

Status: NEW

(Core :: Layout: Tables, defect)

Description

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

After spending a good part of the week fighting with special height reflow code on the reflow branch, I'm filing a bug to suggest that we should (after the reflow branch lands) redesign the way percentage heights work on tables.

I don't think we need the "special height reflow" concept.  I think percentage height handling within tables needs to be done as a pass at the end of table layout -- a pass that looks a good bit like column width computation.  This pass should probably *also* subsume the code that gives all the cells in a row the same height.  Then, when it gives the correct height to each cell, if the cell has percentage-height children (which we now indicate with a frame state bit -- although I'm now probably propagating it only to the inner cell frame, which is probably actually sufficient), we reflow the contents of the cell as though the cell had a fixed height.

Our current behavior is quite far from compatible with WinIE, and I suspect it doesn't need to be as complicated as it is.  I've written a few examples here:
http://dbaron.org/css/test/2006/percent-height-in-tables

I'll try to flesh this out with more details later -- this might not be quite the right idea, but I don't think we need the complex and separate "special height reflow" pass that we have now.

Comment 1

[David W. Jeske]

If this rewrite happens, please include some test examples which involve percentage height/max-height and content with overflow:scroll that is taller than the percentage heights. Compared to other browsers, firefox currently likes to ignore the percentage heights and let the height of the content expand instead of triggering overflow:scroll's scrollbar. 

For example, compare the following example on different browsers.

http://dj1.willowmail.com/~jeske/_drop/htmltest/table-height-percentage.html

Comment 2

[Karl Dubost💡 :karlcow]

The spec is said to be not ready for implementation
https://drafts.csswg.org/css-tables-3/#computing-the-table-height
but a text has been proposed on the issue https://github.com/w3c/csswg-drafts/issues/474#issuecomment-494362828
which aligns on Blink's behavior.

For compat reasons I moved the webcompat Priority to P2. (Note that we have not identified any substantive breakage because of this, or at least we do not have identified that it was the reason for the breakage.)

Comment 3

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

It might make sense to associate compat bugs with more specific bugs rather than a general "rewrite this section of code" bug. (That said, I have a lot less to do with things now!)

Comment 4

[Karl Dubost💡 :karlcow]

Agreed. :) but the percentage thing seems to be all over the place. Probably I or daniel could consolidate this. Thanks David.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I'm looking at this in bug 1883699.

This pass should probably also subsume the code that gives all the cells in a row the same height

Agree, at least that's how I'm planning to handle that (handling percentage sizing right after cell sizing).

Comment 6

[Dennis Schubert [:denschub]]

The WebCompat report linked here is not a real site - it's a testcase. We do not have any real site-breakage for this as far as I can tell - so I'm dropping the webcompat-priority flag here.