CSS 2.1: height of inline boxes incorrectly excludes line gap

• Component: CSS
• Status: RESOLVED INVALID

[Robert Hogan]

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?
#

[Robert Hogan]

*** Bug 80270 has been marked as a duplicate of this bug. ***

[Yi Shen]

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.

[Dave Hyatt]

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.

[Robert Hogan]

Filed a comment at http://test.csswg.org/shepherd/testcase/block-in-inline-001/

Not sure if that will do anything!

[Gérard Talbot]

(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

[Robert Hogan]

Thanks Gerard!

[Gérard Talbot]

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

[Gérard Talbot]

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