Re: line-height suggestions and easier alignment

On 08/01/2012 08:43, Alan Gresley wrote:
> On 5/01/2012 8:12 AM, Alan Stearns wrote:
>
>> On 1/4/12 12:13 PM, "Gérard Talbot"<www-style@gtalbot.org> wrote:
>>>
>>> I am inclined to be against adding anything else until the problems
>>> listed, carefully explained with regards to section 10.8 of CSS 2.1 are
>>> not addressed to begin with. Anything else added into the leading model
>>> (CSS3) needs to be extremely very well justified, substantiated.
>>>
>>
>> Gérard,
>>
>> The basic problem is not being able to control where the leading is
>> applied.
>
> I agree with this premise but a *line box* is only the height of it's
> content. This line box can only be changed by using font-size.
>
> Let me state this with great emphasis, 'line-height' never changes this
> content height and 'vertical-align' does not alter any vertical
> alignment of this content.

I'm not sure I understand what you're saying here.  '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.

<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'.  Since the vertical align is 
'baseline', the baselines of the large letters and the preceding smaller 
letters line up.  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). 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.

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

Received on Sunday, 8 January 2012 11:59:11 UTC