W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: Bert Bos <bert@w3.org>
Date: Tue, 29 Mar 2011 14:37:44 +0200
Message-Id: <FBD83BFB-87FE-4AF1-8143-F4875DA6670B@w3.org>
To: W3C style mailing list mailing list <www-style@w3.org>
On Mar 27, 2011, at 14:29, Anton Prowse wrote:

> The WG has done a fantastic job in fixing up the specification of the inline formatting model, in response to numerous issues raised on it. This important part of the spec is looking pretty solid now.
> In particular, most of the issues I've raised myself have been addressed either on the mailing list or on the wiki, and they either have satisfactory fixes in the current Editor's Draft or have been postponed to errata (which I have no complaint about); the rest have either been fixed or obsoleted as a side-effect of other changes.
> However, there are just a couple of issues which were overlooked.
> #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.

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.

I suggest no change. 

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

But this could be an errata.

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

In other words: not right now.

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

  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 Tuesday, 29 March 2011 13:03:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:57 UTC