Re: A why on inline rendering

Thanks for the tip. I did do some reading there before posting my question, but just to make sure i tried a second run. Unforturnatly this doesn't seem to help me understand the issue. As far as i can see, unless i am missreading the combination of "text-height: max-size" and "line-stacking-strategy: max-height" margin/padding/borders are still ignored in (horizontally flowed) non-replaced heights. "text-height: max-height" seems to make it possible to make a non-replaced inline node dependant on its children for its height, but this is not the initial value.

The following ran a bit longish, just to warn off the uninterested reader...

To quote some text in CSS3 that is a part of my lack of grasping the subject: 

http://www.w3.org/TR/css3-linebox/#LineBox
3.1, first paragraph, last sentence:
"The rectangular area that contains the boxes that form a line is called a line box. "
3.1, second paragraph:
"A line box is generally tall (relative) enough for all of the boxes it contains. However, it may be taller than the tallest box it contains (if, for example, boxes are aligned so that baselines line up)."

So far so good, a line box is essentially what anyone would expect. Now two troublesome quotes:

3.1, fourth paragraph:
"Using a constant spacing may create a 'bleeding' effect between line boxes."
3.1, final pagraph:
"Although margins, borders, and padding of non-replaced elements do not enter into inline box block-progression dimension calculation (and thus the line box calculation), they are still rendered around inline boxes. This means that if the block-progression dimension of a line box is shorter than the 0outer edges of the boxes it contains, backgrounds and colors of padding and borders may "bleed" into adjacent line boxes. However, in this case, some user agents may use the line box to "clip" the border and padding areas (i.e., not render them). "

What are the reasons this last paragraph is good? When is it ever beficial to have the bleeding effects from lineboxes? What is the advantage of talking about boxes when it seems to the casual reader that a box always includes the margin/padding/border? (What is the box-height of an inline non-replaced element with a padding?) 

Sorry to be daft about this, but i really did hope for a reply that gave a simple reason for why i was having trouble with those basic issues with the box model in inline rendering.

 /Staffan

PS as a side note, should those really be optional?
"However, in this case, some user agents may use the line box to "clip" the border and padding areas (i.e., not render them)" 
"When more than one font-size is used (this could happen when glyphs are found in different fonts), it is recommended that the largest font-size provides the em square and the cell-height."


From: "Michel Suignard" <michelsu@windows.microsoft.com>
> You may want to read the following document to see latest thoughts on the subject at http://www.w3.org/TR/css3-linebox/
> (an update should be available soon, but the part describing 'text-height', 'line-height' and 'line-stacking-strategy' have been fairly stable.)
> 
> Michel
> 
> -----Original Message-----
> From: Staffan Måhlén [mailto:staffan.mahlen@telia.com] 
> 
> Hi,
> I'd like to know why non-replaced inline rendering works the way it does. The archives have many interesting discussions on how it is done, but i failed to find explanations on why. 
> 
> To try and clarify my questions somewhat; what is the advantage of having non-replaced inline nodes height dependant on font-height rather than children height (that is, including margin/padding/border etc)? Further, what is the advantage of having line-boxes not always being as high as the contents within them?
> 
> Any pointers would be greatly appreciated,
>  /Staffan
>

Received on Wednesday, 26 February 2003 13:37:33 UTC