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:52:09 -0400
Message-ID: <3d679f3b3898edcda75f05a6ea271063.squirrel@ed-sh-cp3.entirelydigital.com>
To: www-style@gtalbot.org
Cc: "Roger Baker" <tstartme@hotmail.com>, www-style@w3.org

Le Dim 6 mai 2012 2:16, "Gérard Talbot" a écrit :
> 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.



For definition of terms:


> We had a discussion over all this before.

Got it:

Subject line was:
"line-height suggestions and easier alignment"
and it started in january 2012


More tests on inline boxes and line box:

By highlighting/text-selecting the glyphs (you must be using Firefox or
Konqueror or Opera; it won't work with webkit-based browsers), you can see
where (uppermost and lowermost points of glyphs) and how tall are the
inline boxes: the last glyph clearly exceed the (painted green) line box
and they exceed the numerical value they represent.

Same thing here: by highlighting/text-selecting the glyphs, you can see
that the inline boxes are taller than their value.

No problem here: the inline boxes are exactly the height of their value.
Because the glyphs height are exactly what the font-size is.

You must install Ahem font for several tests.

Your browser must have the 'medium' font-size set to 16px.

CSS 2.1 Test suite RC6, March 23rd 2011

Contributions to CSS 2.1 test suite

Web authors' contributions to CSS 2.1 test suite
Received on Sunday, 6 May 2012 06:52:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC