Sorry for the hard-to-parse bug title; it's complicated. When a child of a table cell uses box-sizing:border-box and a percentage height, its border and padding are counted twice when resolving the height. This results in the child being shorter than it's supposed to be. In the reduced testcase (linked from the url), the green child is set to height:100%, so it should fully cover the red table-cell. This bug is making it smaller, so you see red poking through.
Created attachment 127666 [details] ProposedPatch
Comment on attachment 127666 [details] ProposedPatch View in context: https://bugs.webkit.org/attachment.cgi?id=127666&action=review > Source/WebCore/rendering/RenderBox.cpp:-2151 > - if (includeBorderPadding) { > - // It is necessary to use the border-box to match WinIE's broken > - // box model. This is essential for sizing inside > - // table cells using percentage heights. > - result -= borderAndPaddingLogicalHeight(); > - result = max<LayoutUnit>(0, result); > - } This looks like it was an intentional quirk? This didn't change any other test results?
(In reply to comment #2) > (From update of attachment 127666 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=127666&action=review > > > Source/WebCore/rendering/RenderBox.cpp:-2151 > > - if (includeBorderPadding) { > > - // It is necessary to use the border-box to match WinIE's broken > > - // box model. This is essential for sizing inside > > - // table cells using percentage heights. > > - result -= borderAndPaddingLogicalHeight(); > > - result = max<LayoutUnit>(0, result); > > - } > > This looks like it was an intentional quirk? This didn't change any other test results? The comment says that it is done to match with WinIE. But I tested with IE9 and it gives me the same height for table-cell and child element. Looks like IE changed their behavior. Also as per the spec http://www.w3.org/TR/css3-ui/#box-sizing0, if box-sizing is set to content-box, the padding and border of the element are laid out and drawn outside the specified width and height. This cannot be achieved if we subtract padding and border values. Layout test in local machine gives lots of unwanted failures, so I will wait for the bot. It might fail some tests.
Comment on attachment 127666 [details] ProposedPatch Making the patch obsolete as it failed some of the table related tests in local machine. Any thoughts whether this change is desired in webkit as per comment#3 ? I will update the table test cases and resubmit the patch if we decide to go ahead with the change.
(In reply to comment #4) > (From update of attachment 127666 [details]) > Making the patch obsolete as it failed some of the table related tests in local machine. Any thoughts whether this change is desired in webkit as per comment#3 ? I will update the table test cases and resubmit the patch if we decide to go ahead with the change. Yes, the current behavior is definitely both against-spec and nonsensical. I suspect that the quirk in comment#2 is about old IE's use of the border-box model by default, and it's causing things to now be double-counted in this situation when border-box is explicitly used. Given that IE > 6 switched over to the proper box model, this is likely a quirk that we no longer need to worry about. How old are those lines?
This is still an issue: https://stackoverflow.com/questions/46372207/safari-adding-padding-to-table-cell
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.