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

On Mar 29, 2011, at 20:46, Anton Prowse wrote:

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

The sentence has always been just a placeholder, to give the DD element some content. In the old REC, there was another, precise sentence just before the list, which defined the height of both inline replaced and inline non-replaced elements. The DL only defined the possible values, not what they meant on individual elements. That is still the case, although it is less obvious without the sentence about replaced elements just before it.

So I don't see the sentence as contradicting anything. It just restates the obvious: the value serves to influence the line height.

But we could remove the sentence, if people find it confusing. I don't know if the WG wants to do that today or after REC.

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

The paragraph that says to use the box whose height is 'line-height' is only a few weeks old, the rest is 1998 writing style. :-) We even had a technical writer back then to put things in logical order. We didn't think it necessary to repeat under 'sub' what was already said under 'baseline'.

I wouldn't mind replacing

    > the baseline of the box

with something like

    | the baseline of the box (or the bottom margin edge,
    | if it has none)

at some point. But it seems not very urgent. People have apparently understood the original spec.

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



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 30 March 2011 12:24:30 UTC