{css1} line height calculations shouldn't consider text

VERIFIED FIXED in M11

Status

()

Core
Layout
P2
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: dbaron, Assigned: buster)

Tracking

({css1})

Trunk
Other
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
It seems that there are some points where you are considering the size of text
in line-height calculations.  You seem OK on Ian's test:

http://www.bath.ac.uk/~py8ieh/internet/eviltests/lineheight.html

However, there are problems in

http://www.fas.harvard.edu/~dbaron/csstest/linebox3

in the first and fourth paragraphs.  There is too much spacing at the bottom
edge of the line containing the big text.  You seem to be expanding the line
box to hold the text.

Similarly, in the *body text* of
http://www.fas.harvard.edu/~dbaron/csstest/inlinetest
the appearance of an orange X increases the line height at the top, but it
should not (or at least not by nearly as much as it does).  (Could this,
instead, be caused by your interpretation of the block-level element setting
the minimum height of an inline box thing, which I think is a mistake in the
spec. - I think you should ask H&kon about this).

Somehow you need to go down to all *elements* within a line, but not those
boxes that aren't elements.  (But you still need the minimum thing for lines
that don't have any elements within them.  I think this should be done using an
anonymous inline box that wraps the whole paragraph, but...)
(Reporter)

Comment 1

19 years ago
This problem may also occur (but I'm not sure) in the :first-letter in

http://www.fas.harvard.edu/~dbaron/sat/na/

Updated

19 years ago
Status: NEW → ASSIGNED
David posted about this error in the spec back in January:
http://lists.w3.org/Archives/Public/www-style/1999Jan/0027.html
I think another way of describing the problem is that you are
apparently defining line-height as max(font-size, line-height)
instead of just basing it on the line-height property's value
(which might be relative to the font-size, but that is irrelevant).


According to the specs, for a piece of text with:

   TEST { font-size: 6px;  line-height: 1px; }

The boxes are set out like this:


     ___________________________________ top of font-size


     ###### ######  ####  ######
       ##   ##     ##  ##   ##
     --##---#####---###-----##---------- line-
     --##---##--------###---##---------- height
       ##   ##     ##  ##   ##
     ..##...######..####....##.......... baseline

     ___________________________________ bottom of font-size



...and thus if the above element appeared in a line with

   XYZ { font-size: 1px;  line-height: 1px; }

...on either side, the line should be aligned like this (note that
the font-size is irrelevant):


     ___________________________________ top of font-size


     ###### ######  ####  ######
       ##   ##     ##  ##   ##
     --##---#####---###-----##---------- line-
     --##---##--------###---##---------- height
       ##   ##     ##  ##   ##
 .XYZ..##...######..####....##..XYZXYZ.. baseline

     ___________________________________ bottom of font-size


...which would make the inline boxes look like this:

     ###### ######  ####  ######
       ##   ##     ##  ##   ##
     --------------------------- TEST inline
     --------------------------- box
 ____  ##   ##     ##  ##   ##  _______ XYZ inline
 ____  ##   ######  ####    ##  _______ boxes


And thus, if the surrounding lines all had:

   OTHERLINES { font-size: 1px; line-height: 1px; }

...then the surrounding line boxes would be placed above the TEST
element's *inline box*, not above the font. This is because the line
box of the TEST element's line would be like this:

 ------------------------------------- top of previous line box above
 ----------------------------------- top of preceeding line box above
 ------------------------------------------------- top of line box
       ##   ##        ###   ##
       ##   ##     ##  ##   ##
 _XYZ__##___######__####____##__XYZXYZ____________ bottom of line box
 _________________________________ bottom of following line box below
 ______________________________________ bottom of next line box below


...thus the final rendered output would be:

 OTHERLINESOTHERLINESOTHERLINESOTHERLINESOTHERLINES
 OTHE######O######NE####ER######THERLINESOTHERLINES
 OTHERL##ESO##ERLIN##OT##RLI##SOTHERLINESOTHERLINES
       ##   #####   ###     ##
       ##   ##        ###   ##
       ##   ##     ##  ##   ##
 ZXYZ  ##   ######  ####    ##  XYZXYZXYZXYZXYZXYZX
 OTHERLINESOTHERLINESOTHERLINESOTHERLINESOTHERLINES
 OTHERLINESOTHERLINESOTHERLINESOTHERLINESOTHERLINES


I hope that was clear enough. (I also hope it was right. But if it is wrong,
I am sure David will correct me now...)

Note that the font-size *should* be used to decided where the padding,
borders, and background are drawn. This is currently working fine, and
is not related to the issue described above.
(Reporter)

Comment 4

19 years ago
Exactly.  This bug is quickly looking like bug 1990.
Incidentally, this is mainly covered by CSS2 section 10.8.1.
  http://www.w3.org/TR/REC-CSS2/visudet.html#q22

Updated

19 years ago
QA Contact: 4144 → 4110
Summary: line height calculations shouldn't consider text → {css1} line height calculations shouldn't consider text

Updated

19 years ago
Severity: normal → critical
Priority: P3 → P2
Target Milestone: M15 → M11

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

19 years ago
THe code has been revised to not consider text. Life is good...

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 7

19 years ago
Using 9/16 Apprunner and
the http://www.fas.harvard.edu/~dbaron/css/test/inlinetest textcase, verified
fixed.
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
Sorry for the spam...
You need to log in before you can comment on or make changes to this bug.