Re: line-height suggestions and easier alignment

Le Lun 9 janvier 2012 1:41, Anton Prowse a écrit :
> 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.
>

I restore the large 'e' and 't'.


>>> <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.

I restored "tept" (instead of "text") and changed black color to lime. The
color lime is important because it clearly, visually shows where (previous
line box and following line box) and how (above previous line box and
under following line box) bleeding out occurs. The previous line box is
bled over while the next line box is bled under.

>
>>> 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.


It's also bleeding under and not above. That's why I wanted to use "p" in
your example (and a bright color) so that we could see where and how the
bleeding of glyphs is occuring.

regards, Gérard


>
>
>>> 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
>
>


-- 
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 Monday, 9 January 2012 17:57:48 UTC