Re: line-height suggestions and easier alignment

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


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


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


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



> Hence the line box's top intersects the hole in the large
> 'e' and its bottom is a little below the lined-up baseline.
>
>
>>> Specifically the part of 10.8.1 that divides the leading and adds half
>>> to
>>> the top and half to the bottom. Not all typographic systems work that
>>> way
>>> (as you found in your wikipedia research). Adding a property to modify
>>> how leading is applied could ease the impedance mismatch.
>>
>> This can be done but it has to be a change to the CSS line box. What you
>> are proposing is a new CSS box within the current CSS line box which has
>> upper and lower parts that can behave like adjustable leading.
>
> I don't agree that the proposal introduces a new box, but I do agree
> that it changes the line box behaviour (which is precisely what Ric
> wants).  If you can choose whether leading is split into half-leading
> and distributed on either side of the guide box, or whether it is placed
> entirely at the top of the guide box or entirely at the bottom, then you
> are in effect choosing the vertical position of the guide box with
> respect to the corresponding inline box.  In my example above, had the
> leading been entirely at the bottom (which is what the Ric wants for his
> heading) then the guide box of the span would be visibly much higher up
> the larger text and, since the alignment is still baseline, the inline
> box would be much taller and none of the larger text would bleed into
> the line box that sits above it.


One thing I did to your example is replace "text" to "Éxpt" and colorize
it with lime color so that we could clearly see the bleeding over the
previous line and the bleeding "under" the following line.


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.



> I don't see any theoretical problem with Ric's proposal to be allowed to
> control the leading position.  We would need to consider what the
> vertical-align values 'top', 'bottom' and especially 'middle' are
> supposed to do though.
>
>
> 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

  So:
>
> ----- /^\
> |   | 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

regards, Gérard
-- 
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 02:51:59 UTC