Mozilla currently *sets* the font size in the correct way (i.e. em square), but it draws the background relative to nsIFontMetrics::GetHeight, which returns the *bounding box* height of the Western font and not the em-square height. So, the background is being calculated in the wrong way. Bug History: see bug 4234, bug 13072. See also bug 27164: "update nsIFontMetrics API". The test case to look at is: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight4.html This test page uses a font called Ahem, designed by Todd Fahrner. Instructions for downloading the font are included on the test page itself. The font must be installed before passing a browser through the test. Some more test pages: http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/ http://www.fas.harvard.edu/~dbaron/css/test/inlinetest http://www.fas.harvard.edu/~dbaron/css/test/linebox4 http://www.fas.harvard.edu/~dbaron/css/test/emunit http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight1.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight2.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight3.html

Setting milestone to M15 as per bug 27164, which this bug depends on. See also bug 27874. Adding css1 keyword.

Accepting for now, may pass to Gecko group once I've changed nsIFontMetrics.

Since background is not as important as line-height, and since 20394 is targetted for M16, I'm targetting this bug at M17.

Are you sure our current behavior is wrong?

Yes.

As per meeting with ChrisD yesterday, taking QA.

David: In fact, you test for this in one of your testcases: http://www.people.fas.harvard.edu/~dbaron/css/test/linebox4

The CSS spec doesn't say how to handle fonts whose font size is bigger than their Maybe I changed my mind.

Maybe? ;-) The reason I still believe this bug is valid is that if we just let the background cover the bounding box of the font's glyphs, then the results are much more unpredictable. What if you happen to trigger a very cursive font with huge curly descenders? Then the background will spread up and down by several lines for no obvious reason, which will look odd especially on lines where there are no such glyhs.

If you have a cursive font with really big descenders, how do you decide where to draw the background? If you pick the middle of the bbox, it might not end up behind the letters...

You draw the background in the em square. That is (finally) well defined. We know where the em square starts and ends (or rather, we know the em square height and we know the position of the baseline in the em square -- right?). Authors can then add padding if they want more background. But if you let the background cover the entire bounding box, you can't add negative padding to put it back to the 'line-height'... Also, imagine what it would look like if you have line-height:1.2 and a background on the inline element spanning the block. Nice lines with 0.2em transparent 'slits' between them, guarenteed. You can't [easily] get that effect if you use the bounding box height.

nsbeta3- per bug meeting w/ ekrock.

Per CSS WG meeting, we are now per spec. The spec has been loosened so that both the current and perviously only correct behaviours are correct. In the future, this may be controlled by a pref.

Mark it as M23

I'm taking this because it is NOT A BUG but I want to keep it on my radar until CSS3 addresses the issues.

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

ok, wg has dealt with this