Re: Proposal: text-vertical-position property

On Thu, Jan 24, 2008 at 12:01:19PM -0800, David Perrell wrote:
> 
> Ben Cotterell wrote:
> | I think this is really what vertical-align is already for.  More values
> | for vertical-align (various flavours of "middle"), in conjunction with a
> | tighter definition of how inline box heights are calculated, might be a
> | way to achieve this.
> 
> My perception is that vertical-align aligns an inline box within the
> parent's line box;

Yes, although it's also really a process of aligning an inline box
inside another inline box.

An inline box has a baseline, ascent, descent, x-height etc. Those
reference points are used to align child inline boxes within it
depending on the child inline boxes' values of vertical-align.

Having lined everything up, you work out the line-box height, which you
then might have to grow a bit more to reach the maximum line-height set
by the block box.

This is why if you set line-height: 100px and vertical-align: top on a
block, the text inside it doesn't actually end up at the top of the line
box at all.

At least I think that's the reason. If you look at the specification, it
tells you that vertical-align: top means "align [..] with the top of the
line box". Reading that you _would_ expect the text to be at the top.

But in 10.8 we find what may be the answer. There is a four-step
procedure for working out line box height. This implies that
vertical-align is done _first_, before line box height has been
established. So it's not really alignment within the line box of the
inline boxes that you're setting at all, but rather mutual alignment of
the inline boxes with each other. After doing that you determine a line
box height, which you might grow if necessary (step 4).

But if you did grow it, you don't then subsequently move the inline
boxes to realign them in the line box now that you know how big it is.
This is why you end up with vertical-align: top text not actually at the
top of the line box at all.

This is my guess at the interpretation that many browsers (Firefox,
Opera, etc.) are using here.

It seems to me that another interpretation of what the specification
says would be for vertical-align: top and bottom to align to the top and
bottom of the final line box. i.e. do those two after step 4 of the
procedure, not as part of step 2. The new vertical-align properties to
implement the behaviour you want would then be in the same category as
top and bottom (on this interpretation) not in the same category as the
current middle.

You could then just set line-height: 200px, font-size: 100px, and
vertical-align: special-new-middle on the block and get precisely
vertically-centered text 100px high in a 200px box.

I have to say vertical-align and line-height is by the far the hardest
part of the specification to make sense of.

> much different than aligning text within the inline box.  If you move
> an inline box up relative to the parent then you increase the height
> of the line box.

It can do, although not always. If you have some text in a big font
followed by some in a smaller font with vertical-align: middle, the
smaller text will move up but the height of the line box will stay the
same.

> Rather than move the text upward within the inline box, this has the
> effect of increasing the depth of the line box.

If you had a property to align text in inline boxes, then I think you
would also need to tighten the definition of inline box height (10.6.1),
and probably to allow height or min-height to be set on them.

A browser might just make the inline box height the union of the glyph
bounding boxes. You therefore couldn't move the glyphs up or down at all
without them overflowing the inline box, and life is complicated enough
without glyphs overflowing inline boxes.

So I suppose you could set the height of the inline box to some value
greater than its font-size and then align the text in it with this new
property.

But I would actually prefer to make vertical-align: top | bottom |
new-kinds-of-middle align to final line box. I think that's simpler.

> | But the biggest practical problem is going to be getting the
> | information out of the font. Fonts just don't tell you things like
> | the heights of capital as opposed to lowercase letters. 

> Font metrics for scalable fonts include the information needed.

> In Windows, the font metrics structure provides height (ascent +
> descent), ascent, descent, internal leading (a misleading name, as it
> actually refers to the area between the top of the font's bounding box
> and the top of the tallest ascender, i.e. the area where the uppercase
> diacritics reside.) Glyph metric structures provide cap height and
> x-height. I don't see how any GUI can support accurate display
> rendering without this info. 

That may be the case in Windows, but what does cap-height mean for, say,
a Chinese font? I'm not sure you even get x-height in all fonts, you
just have to guess it from the em-height.

-- 
Ben Cotterell
Senior Software Engineer, ANT Software Limited

Received on Thursday, 24 January 2008 23:47:07 UTC