Re: line-height suggestions and easier alignment

On 10/01/2012 10:12, Alan Gresley wrote:
> 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.

I'm struggling to follow your example without an actual webpage test 
case to inspect.  But in general, if the 'line-height' is 'normal' then 
glyphs on different lines shouldn't overlap assuming a typical font in a 
reasonable implementation, since it's a multiplier in the interval [0, 
1.2] of font size and hence leading would typically be positive.

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

Possibly.  The things with coloured backgrounds are almost certainly 
inline boxes.

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

Because it's rectangular.  But it's not a box in the sense of possessing 
the standard CSS box model.

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

?

line-height evaluates to a distance or a multiplier.  It's definitely 
not 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).

Could you clarify specifically?  No inline box "begins" above the top of 
its containing block.  Beware the meaning of "begins" though; since the 
spec likes to think of the height of an inline box to be line-height 
high, the actual content of the inline box might be taller and hence 
bleed out of the vertical "boundaries" of the box.  This is precisely 
why I dislike this construction, and prefer to think of the box that's 
line-height high as being the "guide box", leaving the "height" of the 
inline box itself vaguely undefined as per all other boxes in the spec 
so that we don't have the strange concept of a box whose height is less 
than its content area height.  Looked at like this, the inline box 
visually appears to "begin" above the top of the containing block... but 
that's not really where it begins though.  It's the same kind of 
situation as when a negative top margin on a block-level box makes the 
box appear to begin further up the page than it really does.

>> # [...] 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)?

I don't follow you.  In general, the line box isn't necessarily the same 
height as its strut or any given line-height value on the inline boxes 
it contains; it's frequently taller.  (It's never smaller.)  From 10.8:

   # 3. The line box height is the distance between the uppermost box
   #    top and the lowermost box bottom. (This includes the strut [...])

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

It becomes clearer that there's a big blue vertical gap between your 
yellow boxes, and hence the yellow boxes cannot indicate line boxes 
since line boxes have zero separation except in certain situations 
involving the presence of floats.


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

Not really.  My model is isomorphic to the model described in the spec, 
with the only difference between the two models being that which I 
described clearly in my previous post: my "guide box" is the spec's 
"inline-level box" in the cases where the spec thinks such boxes are 
line-height high.  Where spec thinks of "inline box", I think of "inline 
box overlaid by a guide box".  This allows me to have both a box which 
is line-height high (viz. the guide box) and a box for which "height" is 
not really a defined term but which has a content area height that may 
be different the line-height (viz. the inline box).  I introduce guide 
boxes merely so that I don't have to deal with an box type that has a 
height that bears no relationship to its box model dimensions.  The spec 
chooses not to do that... unwisely, in my view.

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

10.8 describes how the "height" of an inline box is the line-height in 
two places, and alludes to it in various other places.

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

I don't understand the question.  This is the definition of the line 
box.  It's not a box in the usual CSS sense, that of possessing a box 
model.  It's just a rectangle.

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

No idea, sorry.  If what you called a line box is always line-height 
high, then yes.  Otherwise, perhaps what you called a line box is an 
inline box.  A line box is a rectangle that typically spans the width of 
the content area of the box which establishes the inline formatting 
context in which the line box participates.

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

?  That the spec is confusing is a given.  I don't think it's inaccurate 
in any deep way though (ever since the considerable clean-up that it's 
undergone).  I try to avoid the use of the term "height" on any box, 
though, since that's where the holes appear in the spec.  When you 
encounter the term "height of a box", just beware that what it's 
intended to mean in one context isn't necessarily what it's intended to 
mean in another.  It's safer to avoid the term altogether when 
discussing with others.

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

I'm not sure that's very helpful.  Best to stick to the CSS meaning of 
the terms it defines where possible.  (By contrast, "height [of a box]" 
is not universally defined and is used inconsistently, which is why I 
prefer to avoid it.)

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 10 January 2012 21:24:00 UTC