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

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

From: James Aylard <jaylard@pixelwright.com>
Date: Thu, 29 Mar 2001 17:45:57 -0800
Message-ID: <030f01c0b8bb$2b9760b0$2161398a@newcos.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "ValerieGSharp" <ValerieGSharp@netscapeonline.co.uk>, <www-style@w3.org>, "Tantek Celik" <tantek@cs.stanford.edu>

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

    Mozilla's approach makes sense if text (or some non-replaced inline
element) is present. I don't see why my suggestion would undo Mozilla's
formatting for typographic elements.

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

    But many of these approaches have side-effects in other browsers that
make them undesirable, or require additional and potentially more complex
coding (such as extensive use of classes or ids on tds). As well, I see
these approaches as being unnecessary with a common-sense table-cell

> 3. Treating replaced inline elements in this manner means that the
>    addition of text (including &nbsp;) would add whitespace where it
>    was not expected.
>    How would it be rendered in your model, considering you have no
>    reference baseline?

    CSS 2 section 17.5.3 [1] already addresses the baseline question:

"The baseline of a cell is the baseline of the first line box in the cell.
If there is no text, the baseline is the baseline of whatever object is
displayed in the cell, or, if it has none, the bottom of the cell box...."

    And the "valign" attribute in HTML 4 [2], though far less robust than
CSS's "vertical-align", provides some guidance.
    The introduction of white space by use of &nbsp; seems like a non-issue
to me, because of course that is text, and the introduction of text into the
cell will potentially change the behavior of the cell (isn't this how HTML
tables already work?).
    Regarding the carriage returns between <img> elements, how are those
handled presently? I believe that most browsers ignore them. Anyway, these
are questions that would have to be addressed, but they don't seem

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

    My primary concern is that this breaks with traditional UA behavior with
regard to tables and images in table cells. Most developers who aren't aware
of the intricacies of the box model -- and more precisely, with Mozilla's
interpretation of them -- will consider the Mozilla/Netscape treatment of
pixel-precise table layouts as simply buggy.
    You have argued that tables shouldn't be used for such layout. While
that is true, to change table behavior in this way ignores the reality that
they *are* used extensively for this purpose, and will continue to be for
quite some time. The Mozilla interpretation thwarts designers who want to
develop standards-compliant pages that are reasonably consistent across
browser makes and that degrade gracefully in legacy browsers.
    I am not convinced that the Mozilla interpretation is correct, but only
that it can be defended under rigorous questioning through citations of the
CSS 2 recommendation. :) I'm not sure whether the original authors of the
box model (and its implications within table cells) are available for
comment and clarification of their intent -- but since we're not discussing
holy writ, that might be pointless, anyway.
    The Mozilla interpretation seems to argue for theoretical purity (as
defined by its own interpretation), whereas it seems there is room for a
little more pragmatic common sense.

James Aylard

1. http://www.w3.org/TR/REC-CSS2/tables.html#height-layout
2. http://www.w3.org/TR/html401/struct/tables.html#adef-valign
Received on Thursday, 29 March 2001 20:45:23 UTC

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