Closed Bug 92896 Opened 23 years ago Closed 22 years ago

HTML "li" element text shifted up with "font size" and "h1"

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: dkarr, Assigned: rbs)

Details

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (Windows NT 5.0; U)
BuildID:    2001072808

When I have an "li" element whose text is wrapped by an "h1" element, it comes 
out correctly.  When I have an "li" element wrapped by a "font size=3" element, 
it also displays correctly.  However, if I have an "li" element which is wrapped 
by both "h1" and "font size=3", then the text of the element is shifted up 
vertically several pixels, somewhere about half the height of the letters.  
Different font sizes create slightly different behavior, but the baseline of the 
text does not line up with the baseline of the line number.

If I move the "bad" "li" element to between the two "good" ones, it still 
displays incorrectly, and the other two are still correct.

If I view the sample in either Netscape 4.7x and IE 5.0, it displays fine.

Reproducible: Always
Steps to Reproduce:
1. View the test file in the browser
2.
3.

Actual Results:  The two bottom "li" samples have the baseline of the text lined 
up with the baseline of the line number, but the baseline of the first line of 
text does not line up with the line number.

Expected Results:  All three "li" examples should have the baseline of the text 
line up with the baseline of the line number.

Here is my HTML sample that demonstrates this (will this be viewed as raw HTML 
in the bug report?)

<html>
 <body>
  <ol>
   <li><h1><font size="3">xxx</font></h1></li>
  </ol>
  <ol>
   <li><font size="3">xxx</font></li>
  </ol>
  <ol>
   <li><h1>xxx</h1></li>
  </ol>
 </body>
</html>
seeing this behavior on Linux build 2001-07-30-08 as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Reassigning to attinasi.
Assignee: karnaze → attinasi
Target Milestone: --- → mozilla1.2
Taking and re-targetting to 1.0. I just happened to pass by the block code and 
saw the XXXldb and looked up in bugzilla and saw this bug. The fix is a simple 
fall over now.
Assignee: attinasi → rbs
Target Milestone: mozilla1.2 → mozilla1.0
Attached patch proposed fixSplinter Review
I changed the testcase when I wanted to test for code coverage and see the
effect of the next comment: "Tall bullets won't look particularly nice here..."
I am attaching it here for reference in case someone later looks up the bug
number that I added in the code. It looks like it can happen mainly in
contrived situations. So, it is probably not worth wasting cycles on this ATM.
Comment on attachment 72336 [details] [diff] [review]
proposed fix

sr=attinasi
Attachment #72336 - Flags: superreview+
Comment on attachment 72336 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #72336 - Flags: approval+
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: