Closed Bug 120414 Opened 23 years ago Closed 22 years ago

line-height CSS property does not behave as expected with table cells

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 87982

People

(Reporter: zwol, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: css2) 

I expected "text-height: 0" to behave like \smash in TeX: the text is
rendered in a box of zero height, no ifs ands or buts.  However, this
is not what Mozilla does; the actual box height is unpredictable.  See
the URL attached to this bug for a sample and further discussion.
Keywords: css2
There is no 'text-height' property.  Fortunately the test case uses 'line-height'.
Summary: text-height CSS property does not behave as expected with table cells → line-height CSS property does not behave as expected with table cells
I'm not sure whether this bug is valid, but I'm not seeing the second column at
all, perhaps due to a problem with anonymous table object generation.
And, FWIW, for the second column, the red border should be drawn around the
exents of the font metrics.  (That's the correct expected behavior.)
(See the errata to 10.6.1 of CSS2, and also section 10.8 of CSS2.)
dbaron - you see only the column with the U+xxxx codes and the column with
the CHARACTER NAMES IN ALL CAPS?  I'm using the 2002011408 build (linux) and
all three columns show up fine.

Sorry about the text-height/line-height thinko.  I've adjusted the test
case to remove some other potential sources of confusion.

IMO, CSS2 10.8.1 is completely unequivocal about what line-height 0 does:

# Values for this property have the following meanings:
#
#  <length>
#      The box height is set to this length. Negative values are illegal.

Is set to this length.  Not is set to the larger of this length and
something else.

Above this quote, it also clearly says that the box height may be smaller
than the height of the contained text, and that the text then bleeds outside
the box.

There aren't any errata for 10.6.1.  I don't see any erratum for any part of
section 10 that would contradict what I quoted.
(I'm looking at http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html)

I see the intended behaviour then on Linux 2002011614 (this WFM).  I'm leaving
this open though as dbaron and bz both don't.
Thanks for clarifying which erratum you meant.

# The vertical padding, border and margin of an inline, non-replaced box
# start at the top and bottom of the font, not the 'line-height'. 

Then the box borders are being correctly placed.  However,

# But only the 'line-height' is used to compute the height of the line box.

the line box is *not* being correctly sized; if it were, column 2 would not
contribute to inter-row spacing, as it clearly does.
> # But only the 'line-height' is used to compute the height of the line box.
> 
> the line box is *not* being correctly sized; if it were, column 2 would not
> contribute to inter-row spacing, as it clearly does.

Your general conclusion is false, although I'm not sure whether it is false in
this particular case since I can't see it.  Elements with a 'line-height' of 0
can contribute to the height of the line, since they still have a box of zero
height.  However, if the *position* of that box is outside of what would
otherwise be the line box, they increase the size of the line box.  Consider the
following, with the large character being in an inline element with
'line-height: 0':

 -----
   |
   |       ---- top of line box, since this is the position of the 0-height box
   |       _____top of line box without the big T
t  |  t    ____ bottom of line box
I think there is a Mozilla bug on small line-height not working correctly in
table cells, though.
That would explain why a lot of the interline space disappears if I take
out the "vertical-align: bottom".  The 0-height box is then put on the
baseline, safely inside the line box.  It still looks wrong to me:
theoretically they should then all be inside the line box, but the line
spacing is still uneven, indicating that some of them aren't.

I would like to know how one is supposed to do what I was originally
trying to do - render text in a large font without having it affect
interline spacing at all, probably with vertical alignment tweaks on
top of that.  This table is either unreadable or looks ridiculous due
to the extra interline spacing.

*** This bug has been marked as a duplicate of 87982 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
 Verified dupe of bug 87982
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.