80010 2012-02-29 23:53:48 -0800 CSS 2.1: height of inline boxes incorrectly excludes line gap 2014-05-31 22:19:38 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID test.csswg.org/suites/css2.1/nightly-unstable/html4/block-in-inline-001.htm P2 Normal --- 47141 1 robert robert browserbugs2 hyatt ian jchaffraix max.hong.shen mitz robert simon.fraser yael oldest_to_newest 568401 0 robert 2012-02-29 23:53:48 -0800 This bug has been around forever and shows up in the linked test from the CSS 2.1 test suite - the red background from the table cell shouldn't show through. InlineBox::logicalHeight() uses FontMetrics::height() to establish the height of the line box, but that is only the height of the text and excludes the spacing below it - resulting in a line box 1 px shorter than it should be. So it looks like it should use FontMetrics::lineSpacing() instead. Fixing this will require an enormous number of test results to be rebaselined so may not be worth the overhead. What do you think? # 574635 1 robert 2012-03-08 22:19:58 -0800 *** Bug 80270 has been marked as a duplicate of this bug. *** 574902 2 max.hong.shen 2012-03-09 08:25:09 -0800 Robert, I spent some time on investigating the bug 80270, and I agree that the FontMetrics::lineSpacing() should be used instead as the logical height of the inline box. In addition, the issue only happens when the lineSpacing > ascent + descent for some fonts. 578663 3 hyatt 2012-03-14 12:42:06 -0700 The test looks invalid to me. Line boxes should not include line gaps. The test is making the assumption that the height of the line box will equal the height of the block, and that's a bogus assumption if the font has a line gap. 578718 4 robert 2012-03-14 13:34:24 -0700 Filed a comment at http://test.csswg.org/shepherd/testcase/block-in-inline-001/ Not sure if that will do anything! 579484 5 browserbugs2 2012-03-15 10:27:04 -0700 (In reply to comment #3) > The test looks invalid to me. Line boxes should not include line gaps. Hello, I need to be extra-sure of what all of you mean by "line gaps". A rule that uses table {font-size: 16px; line-height: 20px;} will have a top-half-leading of 2px and a bottom-half-leading of 2px. And the line box will normally be 20px in height. (Btw, I do see red when I add and use the above rule in Chrome 17 and then more red for topmost and bottommost cells and then more red when I increase line-height. By default, vertical-align is middle for table cells. So, by increasing the line-height value, I should see and I do see more red at the top and below "Line 1" and "Line 3") > The test is making the assumption that the height of the line box will equal > the height of the block, and that's a bogus assumption if the font has a line > gap. The inline boxes (identified with the text "Line 1" and "Line 3") may not fill the line box but the block box background (<span class="block">Line 2</span>) will. > Filed a comment at http://test.csswg.org/shepherd/testcase/block-in-inline-001/ >Not sure if that will do anything! I think I do understand the problem and I will propose a code correction to the test with regards to taking into consideration line-height. I have something in mind... Gérard 579636 6 robert 2012-03-15 12:26:32 -0700 Thanks Gerard! 581150 7 browserbugs2 2012-03-16 17:42:02 -0700 Okay. This is what I am proposing as a replacement for the test: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/block-in-inline-001-ahemGT.html Gérard 1012795 8 browserbugs2 2014-05-31 22:19:38 -0700 Hello all, This test http://test.csswg.org/suites/css2.1/20110323/html4/block-in-inline-001.htm was indeed imprecise. I have proposed http://www.gtalbot.org/BrowserBugsSection/css21testsuite/block-in-inline-001-ahemGT.html and then proposed http://www.gtalbot.org/BrowserBugsSection/css21testsuite/block-in-inline-001.xht as replacement. Somehow, the 2012-02-22 19:52:44 PST Changeset: 2772:c2fb265f7707 commit http://hg.csswg.org/test/diff/2e6c9009b95a/approved/css2.1/src/box-display/block-in-inline-001.xht mishandled this. Gérard