Re: Inline h*ll

<!--
--- Håkon Wium Lie <howcome@opera.com> wrote:
> Also sprach Matthew Brealey:
> 
>  >
>
http://www.opera.com/people/howcome/2000/inline-hades/
>  > 
>  > 
>  > Impressive.
>  > 
>  > However...
>  > 
>  > 11. <P style="line-height: 14pt; font-size:
> 12pt;">11.
>  > This is a paragraph which<BR>contains a <BIG
>  > style="font-size: 300%;">BiG</BIG> element<BR>
> that
>  > will do weird stuff.</P>
>  > 
>  > Since the line-height declaration is 14pt, there
>  > should be 14pt between baselines, regardless of
> the
>  > content.
> 
> No. All inline boxes on the line are 14pt high, but
> the baselines are
> in different positions due to the effect of
> "half-leading". Since the
> inline boxes are aligned vertically on their
> baselines, the resulting
> line box is higher than 14pt.
> 
> Mozilla shows this example in the same manner as
> Opera 4.
Mozilla is very badly wrong, and if Opera is the same,
then it is also very badly wrong.

Calculating the height of a block element:

1.  <q
cite="http://www.w3.org/TR/REC-CSS2/visudet.html#q17">
If it [the block element] only has inline-level
children, the height is from the top of the topmost
line box to the bottom of the bottommost line box.
2. <q
cite="http://www.w3.org/TR/REC-CSS2/visudet.html#q17">The
line box height is the distance between the uppermost
box top and the lowermost box bottom.
3. Inline elements: <q
cite="http://www.w3.org/TR/REC-CSS2/visudet.html#q17">The
'height' property doesn't apply, but the height of the
box is given by the 'line-height' property.</q>

Given <p style="font: 12pt/14pt">
Some text<br>
<span style="font-size: 300%">Some big text</span><br>
Some more text
</p>

Using 1:
a) P has 3 line boxes.
2:
(b) the height of these line boxes is from the top of
the uppermost box top to the lowermost box bottom
3:
(c) the height of the box is given by line-height.

Therefore, the P element is 42pt high - absolutely and
irrefutably, and would be whether the P element was <p
style="font: 12pt/14pt">
Some text<br>
<span style="font-size: 300%">Some big text</span><br>
Some more text
</p>, or merely:

<p style="font: 12pt/14pt">
<br>
<br>
</p>

However, load up this message in Mozilla (and since
you say that Opera is the same as Mozilla, probably
Opera as well), and this isn't so.
-->
<title>
Brief test
</title>
<style type="text/css">
HTML, BODY {padding: 0; margin: 0}
P.bigholder {margin: 0;
padding: 0;
font: 16px/18px sans-serif;
border-bottom: solid 1px green;
color: blue}
SPAN.big {font-size: 160px}
DIV.top {border-top: solid 1px red;
position: absolute;
margin: 0;
top: 55px}

/* Used for other test below: */
.x {font: 100px/10px sans-serif; margin: 200px 0 0;
padding: 0}
.y {font: 100px/200px sans-serif; margin: -105px 0 0;
padding: 0}
</style>
<p class="bigholder">
Some text<br>
<span class="big">big</span><br>
Some more text
</p>
<div class="top">
</div>
<!--
The important part of this test:

The P is 54 pixels high - because it has three line
boxes, each of which has a height of 18 pixels. It has
a border-bottom of one pixel, which therefore will be
55 pixels down from the top of the canvas. The DIV.top
has a border-top of 1 pixel. It is absolutely
positioned 55 pixels down. 

The result therefore should be a red line 55 pixels
down the page, with a green line  immediately below
it. In Mozilla, however, to do this requires top:
104px, which therefore means that instead of the P
element being 54 pixels high, it is actually 103
pixels high [work that one out then!].

It is very important that the line-height declaration
defines the size of the line box - I cannot say
strongly enough how important this is.

<q
cite="http://www.w3.org/TR/REC-CSS2/visudet.html#q17">
When the 'line-height' value is less than the font
size, the final inline box height will be less than
the font size and the rendered glyphs will "bleed"
outside the box. If such a box touches the edge of a
line box, the rendered glyphs will also "bleed" into
the adjacent line box.
</q>

The correct approach to this is:
1. draw three line boxes whose height is determined by
line-height [the number of line boxes to draw is
determined by the glyph widths, letter-spacing
2. place the text 
[it doesn't have to be done in this order; however, by
doing it this way, the fact that line boxes are
stacked without separation is emphasised]

<q
cite="http://www.w3.org/TR/REC-CSS2/visudet.html#q17">For
example, if a piece of text is '12pt' high and the
'line-height' value is '14pt', 2pts of extra space
should be added: 1pt above and 1pt below the
letters.</q>

Thus in the first example, the bottom of the first
line of text is 17 pixels down from the top of the
canvas (16px font-size plus 1px half-leading) - that
is 1 pixel up from the bottom of the line box. The
baseline is slightly up from this.

The second line of text has leading of (18 - 160) =
-142 pixels, and therefore has half-leading of -71
pixels, meaning that the bottom of its text is 71
pixels below the bottom of the line box (107 pixels
down the page) (and the top 160 pixels above this),
and therefore that its baseline is slightly above this
[in theory, I think the font's baseline descriptor
should be used; however, I think descent is more
satisfactory] (not that this is entirely relevant to
the matter at hand)

The third line of text has half-leading of 1px, and
therefore the bottom of its text is 53 pixels down the
page.

Although the second line of text's baseline and bottom
is outside its box, the important fact is that this
doesn't affect (a) the top edge of the third line box,
(b) the baseline of the third line box)

<q>
When the 'line-height' value is less than the font
size, the final inline box height will be less than
the font size and the rendered glyphs will "bleed"
outside the box. If such a box touches the edge of a
line box, the rendered glyphs will also "bleed" into
the adjacent line box.
</q>

----
I think, however, that the inline box area of the spec
needs work, I find it generally unsatisfactory, and
there are some errors:

1. <q>User agents center glyphs vertically in an
inline box</q> - any browser that actually implemented
this would be unusable

2. <q>Empty inline elements generate empty inline
boxes, but these boxes still have margins, padding,
borders and a line height, and thus influence these
[viz. line box heights] calculations just like
elements with content.</q>

cf.

<q>margins, borders, and padding of non-replaced
elements do not enter into inline box height
calculation (and thus the line box calculation), they
are still rendered around inline boxes. This means
that if the height of a line box is shorter than the
outer edges of the boxes it contains, backgrounds and
colors of padding and borders may "bleed" into
adjacent line boxes. </q>
---
I'll leave you with another test:
-->
<div class="x">
Text
</div>
<div class="y">
Text<br>
Some more text.
</div>
<!--
Here, the first P element is 10px high. Its margin-top
is irrelevant - it is only used to separate this test
from the previous example. The first P has
half-leading equal to (10-100)/2 = 45 pixels.
Therefore, the bottom of the first 'Text' is 45 pixels
below the bottom of its line box, that is to say 55
pixels below the bottom of P's content area.

The second P will have the bottom of 'Text' 10 pixels
(the height of P) + 150 pixels  (font-size +
half-leading) = 160 pixels below the top of the P's
content area without the margin-top declaration.
Therefore, to get its bottom the same as the first P,
margin-top: 55-160 =-105 pixels is needed. As such the
correct result of this test is the two 'Text's
precisely on top of each other and therefore
indistinguishable.
--> 

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Wednesday, 12 January 2000 03:57:54 UTC