W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: Issue 118 (Was: [CSS21] Issues with inline formatting model (particularly 10.8))

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 26 Jul 2010 23:53:13 +0200
Message-ID: <4C4E03C9.7010400@moonhenge.net>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org
Bert Bos wrote:
> I have an action item to write text for issue 118[1]. Here it is:
> The current text says (section 10.8.1[2])
>     # User agents center glyphs vertically in an inline box, adding
>     # half-leading on the top and bottom. For example, if a piece of
>     # text is '12px' high and the 'line-height' value is '14px', 2pxs of
>     # extra space should be added: 1px above and 1px below the letters.  
> What is centered is, of course, not the "ink" of each glyph, but the 
> glyph's em-box, otherwise a small letter such as "o" would end up 
> higher than a tall one such as "h" rather then being aligned on the 
> baseline.
> Also, what is centered is not individual glyphs, but the whole run of 
> glyphs. That makes a difference if the glyphs come from a fallback font 
> that has a different baseline position, because some glyphs will then 
> be shifted up or down with respect to other glyphs in order to match up 
> their baselines.
> Here is a rewrite that tries to avoid all confusion:
>     | User agents align glyphs in an inline box to each other by their
>     | baselines and then vertically center them as a group in the inline
>     | box. To find the height of the group, each glyph is replaced by
>     | its em-box and the height is measured from the top of the highest
>     | em-box to the bottom of the lowest one. (If some glyphs come from
>     | a fallback font with a different baseline, they will be aligned a
>     | bit higher or lower than other glyphs, thus the total height may
>     | be more than 1em.) For example, if a piece of text is '12px' high
>     | and the 'line-height' value 'is 14px', 2pxs of extra space should
>     | be added: 1px above and 1px below the letters.

Mostly looks good to me.  However, it fails to answer the question in
[3; Issue 7] of whether the leading is added to the glyphs or to the
content area.  In particular, does the addition of leading change the
height of the content area?

Browsers seem to think that it doesn't.  (Try changing the font-size of
the spans in the test-case in [4], and note how the content area
changes, as seen via the background colour.)  This makes sense; 10.8
doesn't concern itself with actual inline box heights but instead
concentrates on the use of line-height to calculate the line box height
and the vertical alignment of the inline box within the line box.
Indeed, it defers to 10.6 for inline box height calculation, where
height is expressly encouraged to depend upon font and strongly implies
that it doesn't depend upon line-height.

Yet both the current spec and your proposal seem to want to realize
leading as spacing on the glyphs to "center" them in the inline box,
which would be wrong according to the above reasoning.  (There is no
"centering" to be done; the height of the inline box is defined by the
glyphs and hence the glyph group fits snugly in the content area – for
certain values of 'snugly' as suggested by 10.6.1 for example.)

Rather, an appropriate mechanism would be to add spacing to the content
area(*) of the inline box, which  would act rather like a block box
margin insofar as the inline box's interaction with its line box is
concerned (as opposed to the effectively ignored real vertical margin).

(*) Is this the same as saying to add spacing to the inline box?

On a related note, see my previous post.[5]

> [1] http://wiki.csswg.org/spec/css2.1#issue-118
> [2] http://www.w3.org/TR/CSS21/visudet.html#leading
> [3] http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html

[4] http://dev.moonhenge.net/css21/test-cases/inline-formatting/strut.html
[5] http://lists.w3.org/Archives/Public/www-style/2010Jul/0456.html

Anton Prowse
Received on Monday, 26 July 2010 21:54:50 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:48 UTC