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

Re: CSS 2: Table Cells and the "line-height" Property

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 29 Mar 2001 14:28:21 -0800 (Pacific Standard Time)
To: James Aylard <jaylard@pixelwright.com>
cc: ValerieGSharp <ValerieGSharp@netscapeonline.co.uk>, <www-style@w3.org>, Tantek Celik <tantek@cs.stanford.edu>
Message-ID: <Pine.WNT.4.31.0103291405240.972-100000@HIXIE.netscape.com>
On Thu, 29 Mar 2001, James Aylard wrote:
> After reading and re-reading the various related sections of the CSS
> 2 recommendation, I conclude that it *may* be read to mean what Ian
> and the Mozilla team have concluded: that a td (treated as a
> block-level element) containing only inline content (whether
> replaced or non-replaced inline elements) may be assigned a
> line-height by default that is greater than the height of the line
> box generated by the inline content, and that line-height may
> supersede the height of the line box in determining the height of
> the td.

Ok. I'm glad Mozilla's interpretation makes sense to you! :-)

> The greatest weakness of the Mozilla interpretation, however, is
> that it hinges on the assumption that a td be treated as a simple
> block-level element. Yet a td's presumed display property, as we
> know, is "table-cell", not "block". And it does not seem
> unreasonable to me to extrapolate from that difference that a table
> cell will be different from a simple block in its behavior.

That point is arguable, but point taken.

> In that light, I propose (using inexact terminology) that the height
> of a table-cell element, if it contains only replaced inline
> elements, be based on the height of the line boxes of its content,
> and not on any inherited or presumed line-height of the cell.

The reasons I disagree with this are four fold:

1. It removes the possibility to achieve the formatting that Mozilla
   currently implements, and which is typographically nicer.

2. The behaviour you describe can already be achieved using careful
   use of the 'line-height', 'vertical-align' or 'display' properties.

3. Treating replaced inline elements in this manner means that the
   addition of text (including &nbsp;) would add whitespace where it
   was not expected.

4. If the replaced inline elements do not have a parent anonymous
   inline element to provide a baseline, then the behaviour of
   'vertical-align' becomes undefined.

   Take, for instance, the following markup:

       <img src="a" alt="a" height="10" width="10" />
       <img src="b" alt="b" height="20" width="30" />
       <img src="c" alt="c" height="30" width="30" />
       <img src="d" alt="d" height="40" width="40" />

   ...with the styles:

      [src=a] { vertical-align: bottom; }
      [src=b] { vertical-align: baseline; }
      [src=c] { vertical-align: middle; }
      [src=d] { vertical-align: 1em; }

   How would it be rendered in your model, considering you have no
   reference baseline?

As I mentioned before, my interpretation of the CSS2 inline box model
allows for a backwards-compatible rendering if careful use is made of
the 'line-height' and 'vertical-align' properties. (Typically using
values of '0' and 'bottom' respectively, depending on the exact
situation.) What is the benefit of making this the only possibility?

Ian Hickson                                            )\     _. - ._.)   fL
Invited Expert, CSS Working Group                     /. `- '  (  `--'
The views expressed in this message are strictly      `- , ) -  > ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______
Received on Thursday, 29 March 2001 17:26:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:57 UTC