Closed Bug 1279 Opened 26 years ago Closed 26 years ago

margin collapsing around floats

Categories

(Core :: Layout, defect, P2)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: buster)

References

()

Details

The clear property on the floating table lowers the beginning of the text to the top of the table, which it should not. See: http://www.w3.org/TR/REC-CSS2/visuren.html#inline-formatting http://www.w3.org/TR/REC-CSS2/visuren.html#float-position
Well, I've just checked in some improvements that make the page layout much better (12/12/98); however, there is too much vertical whitespace so I'm not quite done yet :-(
The extra vertical whitespace is caused by the margins failing to collapse. (I tested that by modifying the page.) Note (to be read and then ignored): The placement of the floats is technically incorrect, but I think the spec should be changed because the current rules are impossible to implement (i.e., force changes in already-completed layout and possible lead to infinite oscillation between two layouts). Your behavior is what I think it should be. I hopefully will have time to write a long rant about this to www-style over break. Technically, the floating elements should start parallel with the text-top of the (last line of the) H2. I think the current wording of the spec may have actually been an oversight ... i.e., the authors intended it to be the way you do it. (There are other mistakes in the same rules that are, without any doubt, oversights.)
Actually... to elaborate on my last point. Your current method for vertical alignment of floats is not to allow the top margin-edge of a float to be higher than the bottom margin-edge of any block-level element above it. This is roughly the rule that I think was omitted from the spec. However, this leads to a problem when margins collapse. I think the rule that should be added to the spec is that the top margin-edge of the float should not be any higher than the top border-edge of the first block level element after the last block level element to end before the float. This would be unambiguous in the case of collapsing margins, which the first rule is not. It is also the "logical" behavior and the behavior of MSIE.
Forget this next block level element stuff... I think the way you are doing it is fine, except the margins between the non-floating elements should collapse but the margins between the float and the non-float shouldn't. I'm going to post on www-style today...
This problem also shows up in class eleven in http://www.w3.org/Style/CSS/Test/current/sec411.htm
I believe the failure of margins to collapse is also causing problems in the sixth test of http://www.w3.org/Style/CSS/Test/current/sec414.htm . I think there may be a related problem in the second test in the same page, where there is extra space between the first and the second lines.
Forget the comment about the sixth test. Second test only.
Actually... the sixth test is related (now that I remember what I was thinking). According to the spec, its top should be even with the top of the text above it. However, according to my rant above, it is OK as is (see http://lists.w3.org/Archives/Public/www-style/1998Dec/0065.html ). I think you should at least check with someone at the W3C (or Peter) on this...
Summary: clear on floats lowers text → margin collapsing around floats
Changing bug title from "clear on floats lowers text" to "margin collapsing around floats".
Setting all current Open/Normal to M4.
This problem is also showing up on my homepage: http://www.fas.harvard.edu/~dbaron/ where I have the floating icons (Valid HTML 4.0, WSP, etc.). The spacing between the P elements is too big. The problem there is slightly more complicated - the margins must also collapse *through* the div, but you do have 4 adjacent margins, so they should collapse.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4144 → 4110
The problems on my homepage look fixed, but the others remain.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
We now pass this test with todays checkins; try it out in tommorows builds.
Status: RESOLVED → VERIFIED
Verified fixed.
You need to log in before you can comment on or make changes to this bug.