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.
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.
Yeah that bug is bug 87982
*** This bug has been marked as a duplicate of 87982 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 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.