W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: Updates to section 10.8.1

From: Michael Jansson <mjan@em2-solutions.com>
Date: Sat, 28 Feb 2009 21:26:19 +0100
Message-ID: <49A99DEB.4080201@em2-solutions.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: www-style@w3.org
Hi Anton,

Thanks for taking the time to explain this. Please see below for comments.

Em2 Solutions AB
Michael Jansson

Anton Prowse wrote:
> 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.)
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!? :-)

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). I still expect that "line kerning" to work as well. My 
proposal wouldn't affect that.

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

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.

The second behavior would be the default with the suggestion I made. 
Basically, what you see in Firefox with the sample page would remain the 
same *except* the "bold" inline would really be top aligned and not 
centered. If you want middle aligned, then just change the 
vertical-align to middle. Thus, more options here.

I'm questioning the usefulness of the third behavior, although it is 
still possible with the proposal (just set a suitable low line-height 
and vertical-align to middle). From your steps, change the 
vertical-align on the "Anchor" text to any value beside "baseline" would 
cause the "Anchor" to be vertically anchored. This is just plain odd. I 
do understand the math behind it. I just question the rationale and the 
results, which is why I made the proposal. I don't think people will 
understand what text to is vertically centered when they set the 
vertical-align to anything but baseline. (Again, I understand why. I 
just think it is wrong).

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

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. If it is possible to "fix" the spec and thus allow text to be 
vertically aligned without having to explicitly set the height of the 
inline elements on a line, then why not? Are we just lazy? (Kidding ;-)

> Overall, I think that more choice is better than less.
For sure! You must like my proposal then, since it will enable the use 
of vertical-align in cases where it cannot be used today, without 
deducting any functionality.
> 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.
Most satisfactory example. I believe it confirm my understanding on how 
Firefox does line layout. Thanks!
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
Received on Saturday, 28 February 2009 20:27:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:26 UTC