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

Re: line-height suggestions and easier alignment

From: Alan Gresley <alan@css-class.com>
Date: Tue, 10 Jan 2012 20:12:48 +1100
Message-ID: <4F0C0110.1060807@css-class.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: www-style@w3.org
On 9/01/2012 9:58 PM, Anton Prowse wrote:
> On 09/01/2012 04:28, Alan Gresley wrote:
>> On 8/01/2012 10:56 PM, Anton Prowse wrote:
>>> 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:
>> Can you please tell me exactly what you believe is the line box in this
>> test (I believe it to be the span with the yellow background).
>> http://css-class.com/test/css/text/line-box-001.html
> Line boxes have no visual representation. They're certainly not
> indicated by the yellow background of the span, since there are thin
> strips of the div's blue background visible above and below the yellow.

This is true about those strips of blue (an almost doubling of this 
strip appears between adjacent lines when the text has wrapped) but this 
is due to the default value of 'line-height' which is 1.12 times greater 
than the 'font-size'. Below in the ASCII diagram are the vertical 
distances for some Latin glyphs with font-size of 100px (showing the 
letters 'X' and 'p').

_______________  16px  ______________
           _____   7px                |
X       X                            |
   X   X                      p p     |
     X            67px        p   p  80px (div - block)
   X   X                      p   p   |
X       X _____        _____ p p     |
_______________   6px  _____ p ______|
_______________  16px  _____ p ______<-- top of X on new line

If a new line appears below and this new line had the letter 'X', then 
the vertical distance between the 'X's on both lines would be 13px.

The lowest portion of the descender 'p' (8px in Times New Roman) would 
be appear visually below the top extent of the letter 'X' on a new line. 
See "<-- top of X on new line" for the position of this intersection in 
the above ASCII diagram.

If an am to take it that line boxes no visual representation, then this 
would mean that I have used the term 'line box' to described something 
akin to an inline box.

This leads to two question.

   1. If line boxes have no visual representation, the
      why is box (as in line box) used in the wording
      in the first place?

   2. Do you see line-height (the distance between
      vertically centered guide line of successive
      lines) as a box?

> Recall from 9.4.2:
> # In an inline formatting context, boxes are laid out horizontally,
> # one after the other, beginning at the top of a containing block.

I now question this. What is the meaning of boxes in the above spec. I 
will state that some inline boxes begin before the top of a containing 
block (above ASCII diagram and test cases linked in another list message 
as reply to you and Gérard).

> # [...]
> #
> # [...] Line boxes are stacked with no vertical separation (except as
> # specified elsewhere) and they never overlap.

The only thing that has this behavior as I observe is what I have 
described in the second question. This is a box that is the line-height 
(the distance between vertically centered guide lines of successive lines)?

> This becomes even clearer if you repeat your span so that there are
> multiple line boxes in the same div.

How could this be clearer to see if line boxes have no visual 
representation? I not picturing how these "multiple line boxes" are 
positioned in respect to each other.


>>> In CSS21, the leading is the difference between the vertical extent of
>>> the inline box and the height of the guide box.
>> Where is CSS2.1 do you find guide box?
> The construction isn't used in the spec, but it's a simple and accurate
> representation of the CSS21 model.

This is your mental model. It would be so much easier to understand your 
mental model in person. ;-) Much like for me trying to get you to 
understand my mental model.

>  CSS21 is confused about what the
> "height" of an inline box is: one moment it's the content area height,
> and the next moment it's the distance determined by the value of
> 'line-height'.

This really should be defined. To state that CSS2.1 is confused is not a 
good thing and this has lead me to consider the content height to be a 
line box. Where precisely does CSS2.1 say that 'line-height' is an 
inline box?

> Mostly, it's the latter, but I greatly dislike that
> because everywhere else in the spec "height" means content area height.

Depends on what a line box is. 9.4.2 states this.

   | The rectangular area that contains the boxes that
   | form a line is called a line box

What do you conceive as this rectangular area? (thus why I confuse 
rectangular area as a box)

> It's very strange that there is no relationship between inline box
> "height" and the inline box's box model; I think it's a bad design. I
> prefer to talk about the height of my conceptual guide box (which is
> identical to the inline box defined by the spec when it uses "height" in
> the latter sense). So, guide box is what the spec (mostly) calls inline
> box, and for me an inline box's content area height is what I would call
> its "height".

So does this means that what I had called a line box is what you call a 
guide box?

> However, to avoid confusion

Is that possible now?

 > I try to avoid referring to
> an inline box's "height" altogether and instead I tend to refer to its
> "vertical extent".

Guide boxes, vertical extents.... Are we inverting terms that fit with 
metal models and saying that the spec is confusing?

> Note that the spec never actually defines "height" for any type of
> box.[1] It uses it in the sense of content area height for non-inline
> boxes, though. There's nothing technically wrong with defining it in a
> different way for inline boxes, but it's very confusing to do so when
> that isn't made explicit and when the inline formatting model is
> described so incoherently (although hopefully no longer inaccurately!).

So true.

>> I observe that altering the line-height in respect to the font-size
>> creates a gap that can been understood as leading.
> Indeed. Note that the gap can be negative when the line-height is less
> than the inline box's content area height (which is roughly determined
> by font-size).


[snipped the part about the WebKit bug 2]

>> It's possible to have line-height: 0 which shows no leading and
>> overlapping line boxes. The overlap is roughly 80% of the height of the
>> line box (the one I conceptualized).
> Yes, line-height:0 is fine. It means that the guide box is zero-height.
> That guide box is still vertically centred within the inline box though,
> and so the line box will still have positive height unless the vertical
> alignment is constantly 'top', 'middle' or 'bottom' throughout. I don't
> know what you mean by "no leading"; there would be leading unless the
> font size is also zero (assuming sensible font metrics).

I using leading to mean the old hand-typesetting term of leading.

   | thin strips of lead were inserted into the formes
   | to increase the vertical distance between lines of
   | type.

> [1] http://lists.w3.org/Archives/Public/www-style/2010Jul/0535.html
> [2] http://wiki.csswg.org/spec/css2.1#issue-185

[3] http://en.wikipedia.org/wiki/Leading

Regards, Alan

Alan Gresley
Received on Tuesday, 10 January 2012 09:13:36 UTC

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