Closed Bug 226801 Opened 21 years ago Closed 21 years ago

DT with float:left property not properly aligned in special test-case

Categories

(Core :: Layout: Floats, defect)

Product:
Core
Component:
Layout: Floats
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: g01457013, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125 Firebird/0.7+

I believe the following code snippet from the example page is being rendered 
incorrectly by Gecko (tested in Firebird 0.7+ and K-Meleon 0.8):

<html>
<head>
  <style type="text/css">
    #content { line-height: 1.2em; }
    dt { float: left; } 
    dd { margin-left: 12em; }  
  </style>
</head>

<body>
  <div id="content">
    <dl>
      <dt> <tt>item 1</tt> </dt>
        <dd> definition 1 </dd>
      <dt> <tt>item 2</tt> </dt>
        <dd> definition 2 </dd>
      <dt> <tt>item 3</tt> </dt>
        <dd> definition 3 </dd>
    </dl>
  </div>
</body>
</html>

It is a peculiar combination of CSS and <tt> tags within a definition list that 
seems to cause this error. 

If rendered correctly, the output should look like this:

item 1               definition 1
item 2               definition 2
item 3               definition 3

However, Gecko renders this as:

item 1               definition 1
      item 2         definition 2
            item 3   definition 3

The problem disappears after deleting the #content declaration from the CSS. It 
also disappears after deleting the <tt></tt> tags from the definition list. 
Apparantly, this special set of circumstances causes the float:left property to 
be interpreted incorrectly.

The same problem occurs when replacing the <tt> tags by <code>. Tags such as 
<b>, <u>, <strong>, and <em> did not yield the incorrect behaviour.

Reproducible: Always

Steps to Reproduce:
1. Just open the testpage http://mora.port5.com/misc/test.html
Actual Results:  
If the DT lines in the definition list contain items enclosed by TT or CODE
tags, the float:left property seems to be interpreted wrongly. The example page
shows two different results for definition lists that differ only with regard to
those tags.

Expected Results:  
The two example definition lists should be the same, except for the font-face
where it is affected by the <tt> or <code> tags.

I did some further research, and discovered that this behaviour must somehow be 
related to default margins. Replacing line 6:

  dt { float: left; } 

from the example file by: 

  dt { float: left; margin-bottom: 0.2em; } 

will cause both definition lists in the example page to be positioned
incorrectly. Replacing line 7:

  dd { margin-left: 12em; }

by:

  dd { margin-left: 12em; margin-bottom: 0.2em; }

causes both lists in the example to be rendered correctly. Replacing both lines 
at the same time causes only the first definition list to be rendered correctly.

(The exact value of this margin-bottom where these results occur appears to 
depend on the font-size, so you may have to experiment with other values such as
 0.1em or 0.3em.)
Sounds like the real problem is that the second float starts above the bottom of
the first float, so has to be placed to its right....  Do you have the same
font-size set for monospace and serif font?
The behavior described is valid given some (most, in fact) combinations of font
preferences and font metrics.  Since 'line-height' in em inherits as a length
rather than a scaling factor (as numeric line-heights do), this is in fact the
correct behavior under any conditions other than the monospace and non-monospace
font having exactly the same metrics.  (Explaining why that's the case would
take a few pages, but reading http://dbaron.org/css/2000/01/dibm and then CSS2
section 9.5.1 should fill it in, mostly.)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.