Re: line-height suggestions and easier alignment

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. 
  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.
   # [...]
   #
   # [...] Line boxes are stacked with no vertical separation (except as
   # specified elsewhere) and they never overlap.

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

>> 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.
>
> So you are see something which you call a guide box. I understand
> line-height as altering the vertical distance between successive line
> boxes when they wrap to a new line.
>
>> 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.  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'.  Mostly, it's the latter, but I greatly dislike that 
because everywhere else in the spec "height" means content area height. 
  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".  However, to avoid confusion, I try to avoid referring to 
an inline box's "height" altogether and instead I tend to refer to its 
"vertical extent".

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

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

>> 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.
>
> This is true but not all browsers flow line boxes correctly by this
> definition of a vertically centered guide line when they encounter
> floated content. The first browser to do this correctly was Opera. IE8
> followed suit in 2008. It was I believe late 2008 / early 2009 when
> Firefox (Gecko 2) correctly did this and WebKit still does it wrong (see
> first example).
>
> http://css-class.com/test/css/visformatting/floats-with-inline-elements2.htm

This bug isn't related to guide boxes (or equivalently the spec's 
definition of "height" of an inline box).  Rather it's due to Issue 
185;[2] Webkit obviously haven't updated their rendering to match the 
resolution of that issue which clearly defines when a line box can be 
said to be "next to" a float; see the fifth paragraph of 9.5 (Floats).

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


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

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

Received on Monday, 9 January 2012 10:59:09 UTC