Re: A why on inline rendering

From: "Michel Suignard" <michelsu@windows.microsoft.com>
>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. 
>
Why not let non-replaced inline nodes be dependant on font-height + children margin/padding/border for their own height rather than amend the line-stacking? This in addition to a modification allowing the linebox to be as high as the topmost content-area+margin/padding/border and the lowest content-area+margin/padding/border seems more natural to me.
 

Rather longish below,

Thanks for taking the time to answer me, i believe that hint on constant line spacing is precisely the type of info i am looking for. You are obviously the authority on those things, but i am afraid to say that you haven't quite made me see the light. I suspect i may be somewhat unclear in my questions, probably because i don't have the full scope. 

Let me for the record clarify that i realize that this is not as a major issue for users today, but i do see it as a weakness in the recommendations. A user who tries to use a background/border on an inline element containing a bigger inline element or tries to use top/bottom margins/paddings/borders on an inline element will obviously quickly realize that this not working anywhere. There are no interoperability issues here (or very few, i believe the default line-height varies which makes those things look more or less ugly). However, i believe this may allows future recommendations to choose another way, since no content is likely to exist that depend on those properties. 

Let me try and make it more concrete with two examples:

Example 1: unintuitive(?) boxes
CSS:
   .outer {border-style: solid}
   .inner {border-style: dashed; margin: 1px}
Markup:
      <span class="outer">The outer concept contains
         <span class="inner">some inner concept</span>
         but just one such.
      </span>

Example 2: non-replaced content(?) height.
CSS:
   a:hover {background-color: green}
   .inner {border-style: dashed /* just to make it slightly more obvious.*/} 
Markup:
      <a href="http://www.example.com/">Hover, but do not click<big class="inner"> HERE </big>since it is a dummy</a>

Both of those render quite different from what i would see as commonly expected. In fact, it may be fair to say that to actually realize what happens in the rendering of the above, you would be required to be somewhat of an expert on CSS? While it is obviously trivial to create more extreme examples, the way those two very simple examples are specified to render by default indicates to me that there is some kind of mismatch. 

The text-height property of CSS3 allows the second case to render the way i see as more intuitive, using the value max-size. However, why is max-size not the initial value? The way i see it that would make for more natural rendering of non-replaced inline nodes, while not breaking any current documents (obviously, it would break all current implementations).

The first example cannot as far as i can see work reasonably well (without doing rather specialized, probably more or less pixel-based adjustments that force a certain layout using different line-height values on different inline elements). If margin/padding/border worked similarly in for instance block flow, i think it is fair to say their usability and value would have been more than a little reduced. What are the benefits of effectively disabling the use of (top/bottom) margin/padding/border in inline (horizontal) flow for non-replaced elements? Shouldn't this decision be made more explicit in the specs? Further, why is it ok to calculate with margin/padding/border on replaced inline elements but not on non-replaced? 

What would break if max-height was specified to include the margin/padding/border of children and was made the initial value for text-height? Would it disrupt vertical align? Are there significant implementation issues? 

Finally, is the appeal of constant line spacing independent of for instance borders and varying element size? To my mind, if a user specified a top/bottom padding that user expects to have a non-constant line spacing and if element size varies, so should "line height as a whole". It is not obvious to me that large texts need to bleed into previously flowed lines for reasons of constant line spacing. If a border is drawn, it will today be drawn in the line spacing, in effect reducing it to become a non-constant one visually? 

I did read in the archives something to the effect that the border should be seen as a property of the text similar to underline, rather than as a CSS box property so to speak, but i cannot quite see that. I suppose that if this is the view of the WG, then that includes margin and padding, which very much seems like CSS properties rather than text ones.

My current (probably faulty) understanding is that the issues are caused by ignoring margin/padding/borders as well as by the half-leading relation to the line-box height. 

Thanks again for taking the time to fill me in,

Received on Thursday, 27 February 2003 12:48:45 UTC