W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [CSS21] can't account for vertical space between inline box and its block-level container

From: Gérard Talbot <www-style@gtalbot.org>
Date: Sun, 6 May 2012 02:16:52 -0400
Message-ID: <463fce1fc3c37c8b011ce49fc363b756.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Roger Baker" <tstartme@hotmail.com>
Cc: www-style@w3.org

Le Jeu 3 mai 2012 12:26, Roger Baker a écrit :
>
> Hi,I'm trying to account for the space above and below an inline box and
> its block container in a situation such as this:
> http://jsfiddle.net/QAnfr/1/
> As I understand the situation,
> (1) The height of the inline box is equal to the height of its content
> area (em squares) because line-height is set to 1. (section 10.8.1)(2) The
> height of the line box is equal to the height of the inline box's content
> area. (section 10.8)(3) The height of the content area of the block-level
> container (p) is equal to the height of the line box. (section 10.6.3)
> So, the heights of the inline box, line box, and content area of the
> containing block are all equal. Furthermore, the border areas of both the
> inline box and the block-level container are just outside their content
> areas. Given all that, shouldn't the borders of the inline box and its
> block-level container coincide (contrary to observation)?
>
> Thank you,

I recreated your test here:

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/vertical-space-mystery.html


Content area is not exactly font-size; it depends on it, it has a relation
to it but it is not equal to font-size. If you change serif for Ahem
http://www.w3.org/Style/CSS/Test/Fonts/Ahem/
in the test, then content area fits exactly line-height.
By the way, it's more precise to use a font-size that is dividable by 5
and by 2 for many reasons when usign the Ahem font.

"
(...) The height of the content area should be based on the font, but this
specification does not specify how. A UA may, e.g., use the em-box or the
maximum ascender and descender of the font. (The latter would ensure that
glyphs with parts above or below the em-box still fall within the content
area, but leads to differently sized boxes for different fonts; the former
would ensure authors can control background styling relative to the
'line-height', but leads to glyphs painting outside their content area.)
"
CSS 2.1, 10.6.1 Inline, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced

Font-size has to take into account diacritics signs and special
characters: e.g.: É and _ (underscore character) are usually the
characters with respectively the uppermost (max-ascent) and lowermost
(max-descent) parts of all roman letters.

In your test, the glyphs bleed out of line box.

Content area is roughly 1.17 times the font-size in many fonts. Alan
Gresley had done some tests on this.

We had a discussion over all this before.

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Sunday, 6 May 2012 06:17:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:53 GMT