Re: [CSS21] Final issues with the inline formatting model

On 29/03/2011 14:37, Bert Bos wrote:
> On Mar 27, 2011, at 14:29, Anton Prowse wrote:

>> #1) The spec says that "if the height specified by 'line-height' is
>> less than the content height of contained boxes, backgrounds and
>> colors of padding and borders may bleed into adjoining line boxes."
>> I think it's worth clarifying that even content (glyphs) can bleed
>> out.
>
> We could also remove the sentence. The sentence once made sense, but
> CSS2 no longer defines the relation between the content height and
> the line height.

(The sentence still makes sense, but it's true that there's no
relationship between the two lengths.)

> That a small line height can cause glyphs to overlap seems pretty
> obvious. Maybe something for a tutorial, but an implementer can
> hardly miss that the line height is allowed to be smaller than the
> font size, not to mention the fact that the glyphs themselves can be
> taller than the font size in some fonts.

Agreed.

> I suggest no change.

OK.


>> #2) The spec only defines what 'line-height' means on non-replaced
>> inline boxes and block container boxes which establish an inline
>> formatting context.
>>
>> For all other boxes (such as inline replaced boxes, internal table
>> boxes except for table-cell, and block container boxes which do not
>> establish an inline formatting context) we are left to assume that
>> the property has no effect.  (The value is inherited by child boxes
>> though.)  Could we have this stated in the description of
>> 'line-height' in 10.8.1?
>
> 'Line-height' applies to all inline-level elements, because it
> defines what '100%' means on 'vertical-align'.
>
> So maybe it applies to: inline-level elements and elements that
> establish an inline formatting context.

Good point about percentages on 'vertical-align', and your suggested 
change works for me.

However, the 'line-height' property says:

   # <length>
   #     The specified length is used in the calculation of the line box
   #     height. [...]

which is false for inline replaced boxes, and directly contradicts item 
1 in the list of steps at the start of 10.8 (which says that the height 
of an inline replaced box is the margin area height).  Since these are 
the only two places that specify what the height is, and (unusually) 
there are no hints elsewhere to help the reader infer which variant is 
really intended, I think this should be fixed for PR.

> But this could be an errata.

As regards the suggestion you made, I agree.  It's a good suggestion though.


>> #3) The definition of the values of the 'vertical-align' property
>> depend on the baseline of the box, but that that is not defined for
>> inline replaced elements.  Is it assumed to mean the bottom margin
>> edge of the box?
>
> The definition of 'vertical-align' says to use the bottom margin edge
> for boxes that have no baseline. So 'vertical-align' is already well
> defined, no need to define the baseline of replaced elements.

It doesn't say that (any more?); that instruction is only stated for one 
particular /value/ of 'vertical-align', namely 'baseline'.  In 
particular, for 'sub' and 'super' we're not told what to use for the 
baseline.

(Note that it does say that for elements other than inline non-replaced 
elements, the box used for alignment is the margin box... but that 
doesn't help with with determining the baseline!)

We should probably move the key sentence out of the 'baseline' value 
description and make it "global" to the description of the 
'vertical-align' property.

> It might well be a good idea to define that the baseline is the
> bottom margin edge, rather than let boxes have no baseline at all. It
> might shorten some other definitions. But that is a change I don't
> want to make without looking at all occurrences of replaced element
> and baseline first.

Indeed, and that's a somewhat different issue.


>> #4) The baseline of an 'inline-table' is defined to be the baseline
>> of the first row of the table.  But what if it doesn't have any
>> rows?  We should probably define it to mean the bottom margin edge
>> of the wrapper box in that case, to match the behaviour of
>> 'inline-block'.
>
> That seems reasonable.
>
> We apparently have no tests for that case. We can make it an errata.

OK.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 29 March 2011 18:47:26 UTC