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

Re: line-height suggestions and easier alignment

From: Richard Le Poidevin <ric@betleywhitehorne.com>
Date: Mon, 09 Jan 2012 10:05:04 +0000
Message-ID: <4F0ABBD0.3000005@betleywhitehorne.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: W3C www-style mailing list <www-style@w3.org>, www-style@gtalbot.org, Alan Gresley <alan@css-class.com>

Whilst I don't understand the complexities of how the lines are laid out 
in browsers for your reference here is how InDesign handles accents.


They pop out of the top of the box. It looks like the text is aligned 
using the height of capital letters, and accents are placed above this. 
As each typeface is different I guess the exact spaces may vary as some 
could place accents a little differently or have some letters that are 
taller than others etc.



On 09/01/2012 09:41, Anton Prowse wrote:
> 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 10:06:30 UTC

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