Re: Updates to section 10.8.1

Michael Jansson wrote:
> I'm still trying to understand the line layout formatting that is 
> described by CSS 2.1. Having read Mike Eric Meyer's inline formatting 
> model 'cheat sheet' at http://meyerweb.com/eric/css/inline-format.html, 
> I believe it describes what most browsers do (more or less), but I don't 
> like what I see from a typographical point of view.
> 
> I would expect growing the line-height

(I assume you mean the line-height of the block-level element
containing the line boxes that we're interested in.)

> to cause the typographical
> distance between lines to grow and for the *whole* content on each line 
> to be centered vertically *without* affecting the vertical distance 
> between inline elements on that line.  That makes sense from a visual 
> point of view. Applying half-leading individually and independently on 
> each inline non-replaceable element is just plain wrong, in my mind. The 
> behavior is inconsistent w.r.t. use of replacable vs non-replacable 
> inlines at the very least, and basically prevents the vertical-align 
> property from being used on text.

Ah, but the current CSS21 model is more subtle and hence more flexible
than this.  I think it's more enlightening to play with an example than
describe the mathematics, so load up Eric Meyer's test case at
http://meyerweb.com/eric/css/inline-test-1.html in a recent Firefox (eg
3.1b2) with the Firebug add-on installed.  We're going to play with the
first "anchor", which currently bleeds out of the line box in which it
sits, the latter being shorter than we might have naively expected.
Accordingly, the text-align:top <b>bold</b> superficially fails to have
a vertical relationship with the anchor.

Inspect the bold with Firebug and edit the element style to give it
font-weight:normal, because the boldness just complicates the matter
unnecessarily.  Additionally, give it a line-height of 12pt; this is the
same as what it already inherits from its parent, but we want to keep
that value fixed while we change the parent's line-height later.  This 
will avoid its inline box from becoming larger than its content area 
through the addition of leading, and thus it will remain a meaningful 
visual indicator of where the top of the line box is.

What we're now looking at is the "basic rendering", which arises from 
having increased the font-size of the anchor without having specified a 
corresponding line-height.

Now inspect the anchor and give it a line-height of 141pt.  There is no 
bleeding, and the bold is aligned to the top of the anchor at the top of 
the line box.  Now inspect the parent (the <p>), and in the right-hand 
style pane of Firebug, click on the value '12pt' of the
line-height property.  Use the 'up' arrow key to steadily increase this
value, and you will see the effect in real time.  For line-heights up to
and including 219pt, the line box we're interested in stays the same
height and hence the vertical alignment is preserved.  At this point,
the line box is the same height as those on either side.  Increasing the
parent line-height further now increases the height of the line box of
interest because positive leading pads out anchor's inline box, and this 
of course now breaks the horizontal alignment of the anchor with the 
bold, since the anchor has vertical-align:baseline not vertical-align:top.

If I understand you correctly, this is the behaviour that you expected
(and would prefer) to see.  This is what I think of as "word processor
behaviour".  (Try adding vertical-align:top to the anchor during these
line-height changes and I think that is also what you would have
expected too.)

So CSS can do word processor behaviour, but it can do more as well!  I 
actually prefer the basic rendering you get when you remove line-height 
from the anchor, albeit with a the font-size that is much less 
exaggerated.  Give the anchor a font-size of 32pt and compare the basic 
rendering you get with no line-height specified on it to the word 
processor rendering you get with a line-height of 41pt.  The former, 
which involves a bleeding that one could almost think of as "line 
kerning", is nicer IMO.  Similarly, set vertical-align:top and now you 
get a nice vertical centering of the oversize text in the line in which 
it sits, again with "line kerning" (this time on both the top and bottom).

I do agree with your observation that vertical-align:top/bottom are not 
much use on the bold in the basic rendering because the line box is 
shorter than the anchor's content area which you probably want to align 
to,  but it does perform as expected in the word processor rendering.

I also concede that to achieve the word processor rendering you do have 
to set the line-height of each inline box that you set a font-size on. 
But -- and here's the ah-ha moment -- we know that line-height shouldn't 
really be set as a length anyhow, precisely because we want it to be 
inherited as a font-size multiplier and not as a fixed quantity.  Change 
the line-height on the parent to the "natural" number for the font (in 
this case, 1.1) instead of 12pt, remove the line-height on the anchor, 
and you get word processor behaviour without even needing to specify a 
line-height on the anchor.

Overall, I think that more choice is better than less.

Hope this was of interest.  If my "word processor behaviour" was not 
actually what you were seeking, let me know in more detail how you would 
prefer the example to be rendered.

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

Received on Saturday, 28 February 2009 17:07:49 UTC