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

RE: A why on inline rendering

From: Michel Suignard <michelsu@windows.microsoft.com>
Date: Wed, 26 Feb 2003 15:34:47 -0500 (EST)
Message-ID: <84DD35E3DD87D5489AC42A59926DABE901032D30@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
To: Staffan Mhln <staffan.mahlen@telia.com>
Cc: <www-style@w3.org>

See my answer inline:

-----Original Message-----
From: Staffan Mhln [mailto:staffan.mahlen@telia.com] 

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

'text-height' is only about content height determination, so it cannot influence margin/padding/borders  which go beyond content. It still looks to me that if you use 'ine-stacking-strategy:inline-line-height' and define a line-height value large enough to define leading space that contains your marging/padding/border area you would achieve what you want. I guess we could create a specific line-stacking-strategy value to explicitly take into account margin/padding/border, but this seems overkill to me. 

> 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?) 

Note that this text was already mostly in CSS2 (see 10.8.1), in many cases it is more important to have constant line spacing than avoiding at all cost bleeding. Constant line spacing is much more eye pleasing, especially when the bleeding occurrence are very rare. This cases may happen with writing systems with very sparse but extremely long ascenders and descenders (Arabic can be on that case).

Furthermore, when you say that a box always includes margin/padding/border (for a casual reader), a careful reading of CSS will show that the box height and width are typically based on content (except for non replace inline elements where line-height also plays a role). Nowhere marging/padding/border appear there. Again if you want these to be preserved you can adjust 'line-height'.

Received on Wednesday, 26 February 2003 16:45:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:06 UTC