Re: Updates to section 10.8.1

Michael Jansson wrote:
> My premise is that I want to be able to lay out text on a page with 
> exact positioning. Imagine a document where you want to ensure that the 
> height of the page is an exact number of pixels tall and each line has 
> an exact distance from each other. I'm thus laying out text as precise 
> as any word processing application would, ensuring line breaks, page 
> breaks and inter vertical alignment of text on lines. I would thus want 
> control of exact line height of every line of the page.
> 
> Pretty tall order, right!? :-)

On screen, an impossibility in the general case.  Users can set minimum 
font sizes and can zoom text on most major graphical browsers, which 
will break any control you thought you had over line-height.  Their 
browser may also replace any given font with another if the requested 
font does not exist on the system.  (This  last point may become less 
relevant in the future, with the advent of CSS font linking.)

Perhaps you are primarily talking about print stylesheets, where your 
requirements may be more achievable.  Or perhaps these are requirements 
are specific to the browser that you are implementing, in which case you 
could remove the above-mentioned abilities from that browser.

> With this premise, I would expect growing the effective height of any 
> line (no matter how that line height is computed) within a block to have 
> the characteristics that I explained below.  Changing the effective line 
> height (through setting the line-height on either the block, or an 
> individual inline element, or using a tall image, etc) should not affect 
> the vertical alignment of text on that line. If the user want top 
> aligned text, then that is what he should get (which is currently not 
> the case).

Since in CSS21 there is no way of targeting a line box via a selector, 
how would you propose to alter the line-height via individual inline 
elements etc?  Would you take the tallest of the line-heights specified 
for inlines in a given line box to use as that line box's height?

> I still expect that "line kerning" to work as well. My 
> proposal wouldn't affect that.

 > Anton Prowse wrote:
 >> Michael Jansson wrote:
>>> 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.

So if you specified a line-height that was less than the natural height 
of a given line box, the content would bleed?  This sounds reasonable.

It wouldn't be possible for content to bleed non-uniformly (eg more at 
the top than the bottom).  I'm not sure how important this is.

>> 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.  
> I followed your steps and I believe I understand the current behavior in 
> Firefox. You get what you refer as the "word processor" behavior by 
> forcing the height of line box containing the "Anchor" text to be much 
> taller than the height of the "bold" text, thus giving it the room to be 
> top-aligned. This is consistent with the spec, and with the 
> (mis)-behavior that I want to change.
> 
> If I understand your example correctly, you describe three behaviors:
> 1) The "basic rendering" where you have the "bleed" but without vertical 
> alignment of text.
> 2) The "word processing" where you do not have the "bleed" but with 
> vertical alignment working.
> 3) The "top/bottom bleed" which is a similar to the "basic rendering".
> 
> What the "word processing" behavior you have described is an alternate 
> way to achieve what I am looking for, which is great. (Personally, I 
> would rather use "position:relative + left/top" to get the inter-text 
> alignment I want though, but that's just a personal preference). 
> However, I'm not proposing this as web author but as an engineer writing 
> a browser. I'm *very* picky about typography and language support and 
> rather forget about support images and only support text, if I had to 
> chose (just to give you an idea where my focus and experience is). I 
> rather implement a solution that works without having to "fool" the 
> system into doing what it should have done to begin with. E.g. 
> "vertical-align:top" should really produce top aligned text, no matter 
> what, and without side-effects.

I'm inclined to agree, but I do not know the history of the current 
behaviour.  Perhaps other implementors can shed some light on this.

There are many areas of CSS21 which break the principle of least 
surprise, but I would be the first to say that the inline formatting 
model is a world-beater.  However, it may be that there's more 
typographical depth to this than appears on the surface (especially 
given the necessity to support many language systems).  I would be 
particularly interested to hear the opinion of typographers from 
different backgrounds/languages.

> Please note though that what I propose won't affect the subtleness of 
> the current specification (please prove me wrong :-). Specifically, you 
> still get the first behavior. Setting a line-height (for a whole block 
> or for an individual inline element) would cause the whole line (or the 
> inline element) to still "bleed", just like what you see with the 
> current design.

I'm a little confused here; setting a line-height for an individual 
element would influence the whole line box, no?  You don't need to set a 
line-height on the element just to achieve bleeding, because simply 
making the font size large enough to outgrow the existing line-height 
would cause this, if I understand your suggestion correctly.

> The second behavior would be the default with the suggestion I made.

Sure.

>> 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
> Oh no....! You do not want to use relative quantities if you do any 
> serious typography text layout. You do want to lock down on a given font 
> (system or web font), use an exact font size (in pixels) and specify an 
> exact distance between lines. You absolutely have to have that control 
> if you want to control line breaks and page breaks. I'm not saying that 
> everyone needs that control, but that controls has to be available to 
> those that need it. Again, I'm very picky about getting this working 
> correctly from a typographical point of view.

Well, that may be true for your proposed behaviour, but with the current 
behaviour you do do want relative quantities, due to the way the 
computed values are inherited.[1]  As I said above, locking down on a 
given font and font-size is not possible on anything other than a closed 
system.  Of course, under your proposal for more control, using lengths 
instead of relative quantities may be reasonable since you will 
effectively have to set the line-height height every time you change 
font-size.  The idea behind relative quantities is that it saves you 
from having to do this.

> I do concede that there are more than one way to skin the proverbial 
> cat. There are other ways to ensure exact page layout. Still, I don't 
> consider alternative methods to be motivation for keeping defective 
> designs.

I don't know enough about the rationale behind the current behaviour, 
and so I cannot judge whether or not it is defective.

Looking forward to hearing more opinions on this!

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

[1] http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/

Received on Monday, 2 March 2009 21:54:03 UTC