Re: line-height suggestions and easier alignment

On 09/01/2012 03:51, "Gérard Talbot" wrote:
> Le Dim 8 janvier 2012 3:56, Anton Prowse a écrit :
>> On 08/01/2012 08:43, Alan Gresley wrote:
>>> [snipped]

>> 'line-height'
>> certainly does influence the height of line boxes, as does
>> 'vertical-align'.
>>
>> 'font-size' is responsible for the visible "height" of the glyphs.
>> However, this "height" is not a direct factor in determining the line
>> box height and the alignment within the line box.  Rather, 'line-height'
>> determines the height of what I call the "guide box" associated to each
>> inline box.  Think of the guide box as overlaying the inline box, with
>> the same width but with unrelated height.
>>
>> In CSS21, the leading is the difference between the vertical extent of
>> the inline box and the height of the guide box.  Thanks to the existing
>> CSS21 model of leading implemented as two pieces of half-leading above
>> and below the guide box, the guide box is vertically centered with
>> respect to the inline box.  (Leading is the result of a calculation
>> rather than an input to a calculation; it's merely an equation balancing
>> exercise.  It would be possible to rewrite CSS21 to avoid all mention of
>> leading.)  Commonly the guide box is taller than the vertical extent of
>> the inline box and hence leading is positive.  It's perfectly possible
>> for the guide box to be shorter and hence leading to be negative,
>> though: just set a line-height that's smaller than the inline box
>> vertical extent that's derived from the font size.
>>
>> The 'vertical-align' values 'top', 'bottom' and 'middle' act on the
>> guide boxes, not on the inline boxes.
>>
>> To see the interaction between vertical-align, line-height and
>> font-size, consider the test case below.
>
> I've put the following (slightly modified version) after/along with Alan
> Gresley code example:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/line-height-leading-AGresley.html

Thanks, although you'll need to change my description because of course 
there is no large 'e' or 't' anymore.

>> <div style="line-height:20px; width:280px">
>>       text text text text text text text text text text text text
>>       <span style="line-height:inherit; font-size:140px">text</span>
>>       text text text text text text text text text text text text
>> </div>
>>
>> Observe how the line box containing the span is taller than the other
>> line boxes, yet not as tall as the span's inline box.  This is because
>> the line-height of the span is smaller than the vertical extent of the
>> inline box derived from the large font size.  (Hence the leading is
>> negative.)  The top of the guide box lies somewhere in the middle of the
>> "hole" in the 'e' (no doubt there exists a technical term for that
>> hole!) and the bottom of the guide box lies somewhere just above the
>> curly tip of the bottom of the 't'.
>
>
> We are assuming here that the distance between "somewhere in the middle of
> the 'hole' in the 'e'" and "somewhere just above the curly tip of the
> bottom of the 't'" is 20px.

Precisely. It's the line-height value.

>> Since the vertical align is
>> 'baseline', the baselines of the large letters and the preceding smaller
>> letters line up.
>
> In your interactive code example, we would see such baselines vertically
> lining up if the width of container was much wider than 280px. More like
> 900px.

That's because you've changed the test case ;-).  In my original test 
case, there were intentionally some small letters preceding the large 
letters in the same line box.  You may wish to reintroduce that 
situation in your derived test case.

>> The line box height is then the distance between the
>> lowest of the bottoms of the guide boxes on the line (which is the
>> bottom of the guide box of the smaller text) and the highest of the tops
>> of the guide boxes on the line (which is the top of the guide box of the
>> larger text).
>
> Would such line box height have been greater (taller) if, instead of
> "text", you had (underscore character É underscore character) "_É_" (or
> "Ép")? I believe it would not have been greater.

 From 10.6.1 (Inline, non-replaced elements):

   # 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. [...]
   #
   # If more than one font is used (this could happen when glyphs are
   # found in different fonts), the height of the content area is not
   # defined by this specification. However, we suggest that the height
   # is chosen such that the content area is just high enough for either
   # (1) the em-boxes, or (2) the maximum ascenders and descenders, of
   # all the fonts in the element. Note that this may be larger than any
   # of the font sizes involved, depending on the baseline alignment of
   # the fonts.

In general, given the two examples in the spec, it's a reasonable 
interpretation that "should be based on the font" means that the inline 
box retains the same vertical extent no matter which glyphs from the 
same font are used.  (Ultimately, though, it's undefined.)  However, if 
there is font fallback then of course there might be an 
uncharacteristically large fallback glyph which causes the vertical 
extent of the inline box to be greater than it would be if there were no 
fallback, which in turn would mean that the vertically-centred guide box 
is higher relative to the baseline than it would otherwise be, which 
would then force the whole line box to be taller.


> With the proposal to have leading all below font, below glyphs
> means/implies that bleeding out would occur under the following line box
> when line-height is less than content height.

Indeed, there would never be any bleeding into preceding line boxes. 
Bleeding, if it occurs (which it would for typical fonts whenever 
vertical alignment is other than 'top' or 'bottom'), would be into the 
subsequent line boxes.


>> On a related note, as Gérard has mentioned already and illustrated in
>> his 'text-top' case in [1], some glyphs have accents and so we must all
>> remember that "lining up" as per Ric's desire doesn't always result in
>> what authors sometimes naively expect.  A common authoring use case is
>> to want to visually align the top of a title with something else, eg an
>> image:
>>
>> -----
>> |   | TITLE
>> |   |
>> |   |
>> -----
>>
>> Frustration results because the top of TITLE doesn't seem to align with
>> the top of the image.  However, that's because there's extra space above
>> the letters where accents would go if there were any.  (Is this space
>> the same space as what's called the "ascender" space?).
>
> Disclaimer: I'm not a typographic expert.
> The acute accent is in the ascent space. The acute accent causes the glyph
> to reach the max-ascender (uppermost point) of a given font. Often the
> uppermost part of the acute accent exceeds the ascender line of the font.
>
> http://cdn.ilovetypography.com/img/vert-metrics/vmetrics.html

Very interesting article, thanks.

>>
>> ----- /^\
>> |   | TITLE
>> |   |
>> |   |
>> -----
>>
>> The ASCII figure doesn't quite capture my point, but you get the idea. I
>> expect that Ric is already aware of that but I thought it worth
>> mentioning anyhow.  No change in the inline formatting model would solve
>> that issue since a certain amount of the "space" that typically sits
>> above a non-accented letter is actually part of that letter in some sense.
>>
>> [1] http://www.gtalbot.org/DHTMLSection/vertical-align-values.html
>>
>> Cheers,
>> Anton Prowse
>> http://dev.moonhenge.net
>
>
> Btw, I have also created another interactive testcase:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/line-height-leading-AStearns.html

You clearly see the space between the top of the "T" and the bottom of 
the green border-top; this space is occupied by the accent above the 
"E".  Hence attempting to "line up" the top of English text with the top 
of a float is futile; but throw in an accented capital letter and it 
becomes obvious why!

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 9 January 2012 09:41:59 UTC