Closed
Bug 146779
Opened 23 years ago
Closed 20 years ago
Float property ignored on elements with negative margin value equal to its width
Categories
(Core :: Layout: Floats, defect, P3)
Core
Layout: Floats
Tracking
()
RESOLVED
DUPLICATE
of bug 148994
Future
People
(Reporter: s1019212, Unassigned)
References
Details
(Keywords: css1, testcase, Whiteboard: [CSS1-5.5.25][CSS1-5.5.26])
Attachments
(2 files, 1 obsolete file)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3)
Gecko/20020523
BuildID: 2002052306
When a element with the float property set has a negative margin-left or
margin-right value equal or greater to it's width, the box's float property is
ignored by other elements with the clear propety set.
Thus, an element with clear:left (or any other value of the clear property) will
not render BELOW the element with the float property set and a negative
margin-left or margin-right value. Instead the element with the float property
set is treated much like an absolutely positioned box.
Reproducible: Always
Steps to Reproduce:
View example in additional information within Mozilla
Actual Results: float element is removed from the flow of the document and any
CLEAR style properties set are ignored. this causes content that should appear
below the float element to appear wherever normal document flow would place it,
ignoring the floated element.
Expected Results: content with a CLEAR style property set should appear BELOW
the floated element.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>CSS Float Property Bug Demo</title>
<style type="text/css">
<!--
#floatbox {
width: 10em;
float: left;
margin-right: -10em;
}
#contentbox {
margin-left: 11em;
}
#footer {
clear: both;
}
-->
</style>
</head>
<body>
<div id="floatbox">
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
Menu Element<br>
</div>
<div id="contentbox">
<p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed
diam nonummy nibh euismod tincidunt ut laoreet dolore magna
aliquam erat volutpat. Ut wisi enim ad minim veniam, quis
nostrud exerci tation ullamcorper suscipit lobortis nisl ut
aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat,
vel illum dolore eu feugiat nulla facilisis at vero eros et
accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi.
</p>
</div>
<div id="footer">
<hr>
This web site is maintained by John Smith, FooBar Designs L.L.C.
</div>
</body>
</html>
|
Reporter | |
Comment 1•23 years ago
|
||
To make life easier, I've attached the example HTML I put in the original bug
report.
|
||
Comment 2•23 years ago
|
||
Chris, this looks like your sort of thing...
|
||
Comment 4•23 years ago
|
||
Mmm, floats.
Assignee: attinasi → waterson
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
|
|
||
Comment 5•22 years ago
|
||
to correct component.
Assignee: waterson → float
Status: ASSIGNED → NEW
Component: Layout → Layout: Floats
OS: Windows 2000 → All
Priority: P3 → --
QA Contact: moied → ian
Hardware: PC → All
Target Milestone: Future → ---
|
||
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
|
||
Comment 7•22 years ago
|
||
The problem seems to be in layout/html/base/src/nsBlockReflowState.cpp. A
calculation for rect.width is done that gives a negative result, so
mSpaceManager->AddRectRegion throws out the region as Empty(). Here's a patch
that fixes the problem, but likely causes something else bad to happen
elsewhere. Or, if we're lucky, maybe it fixes a bunch of other things. But
most likely the former.
The patch is the removal of 4 lines of code that dbaron put in for bug #85876.
// Adjust the floater size by its margin. That's the area that will
// impact the space manager.
region.width += aFloaterCache->mMargins.left + aFloaterCache->mMargins.right;
region.height += aFloaterCache->mMargins.top + aFloaterCache->mMargins.bottom
Probably these lines are needed elsewhere, but they don't quite make sense to
me. Maybe they were supposed to add the border padding?
This patch also fixes bug #182091, but does not affect bug #75286.
|
|
||
Updated•22 years ago
|
Attachment #113099 -
Flags: review?(dbaron)
|
||
Comment 8•22 years ago
|
||
Comment on attachment 113099 [details] [diff] [review]
brute force patch
This patch is wrong. The area that should affect things is the margin edge,
but our internal representation of boxes ("frames") uses the border edge.
The right fix would probably have to do with removing or finding a way around
the IsEmpty check.
Attachment #113099 -
Flags: review?(dbaron) → review-
|
|
||
Comment 9•22 years ago
|
||
Unfortunately, avoiding the isEmpty() call doesn't seem to be an easy solution.
In particular, I got rid of the isEmpty() call, and found new undesirable
behaviour (semi-overlapping instead of full overlapping). Then I found numerous
other isEmpty() calls in nearby files, and disabled them too. Then I brought
out the big guns and made the change in nsRect.h to get any that I might be
missing. No better. Then I noticed other places in the code where checks are
made for width > 0. I changed the ones I found. No better. Then I gave up.
Maybe someone with better knowledge with have better luck, but I'm concluding
that it is going to be quite complicated to get negative margin floats to work
properly if the code continues to use negative width regions. Perhaps there is
some other way to treat this margin information? Maybe one could offset the
coordinates and leave the width as it is? Beyond me, though.
|
|
||
Comment 10•22 years ago
|
||
As an occasional workaround, note that one can set the opposing margin to a
positive number to oppose the negative number used for the desired margin. If
the sum of the margins plus the width of the float is about zero, the layout
will basically work, apart from a tiny indentation of the text that can be
minimized by reducing the amount of opposing positive margin.
Attachment #113099 -
Attachment is obsolete: true
|
||
Updated•21 years ago
|
|
|
||
Comment 11•20 years ago
|
||
This was fixed by the patch in bug 148994
*** This bug has been marked as a duplicate of 148994 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•