295309 - [FIXr]Parent block gets margin from child

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P3)

Description

[Serge]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511

The parent block (div) gets the value of "margin-bottom" from his last child 
box (div)

Reproducible: Always

Steps to Reproduce:
1.Use the following stylesheet:
#main{
	width: 100px; background-color: red; margin-bottom: 0;
 min-height: 250px; 
}
#content{
	width: 80px; background-color: blue; margin-bottom: 20px;
}
#sign{
	width: 20px; height: 50px; background-color: black; margin-left1: 120px;
}

2.Use the following HTML:
<div id="main">
	<div id="content">
		sjhfskj skjfskdfh sdkjfhs klfhlas lasd lasdjk lasdj alsdkj 
alsdkj alsdkjf alsdjk fasldjf alsdk alsdkj aslkdj falskd jf
	</div>
<!--	&nbsp; -->
</div>
<div id="sign">
</div>
3.See the space between red (main) and black (sign) boxes
4.Uncomment "&nbsp;" and see no space there

Actual Results:  
The margin-bottmo from "content" element goes to "main" element, making space 
between "main" and "sign", while "main" hes tjis margin set to 0.

Expected Results:  
No space between "main" and "sign", according to CSS standard

Comment 1

[Steve England [:stevee]]

Serge, can you attach a testcase that shows this behaviour?
https://bugzilla.mozilla.org/attachment.cgi?bugid=295309&action=enter

Comment 2

[Serge]

Attachment: Test case to see the bug

There should be no space between red and black boxes, because margin-bottom set
to only blue one. The behavior is correct only when there is something after
blue box (you can uncomment " " and see it)

Comment 3

[Steve England [:stevee]]

Dupe of/related to bug 292295?

Comment 4

[Serge]

I don't think, this is related to bug 292295, 'cause that bug deals with 
floating boxes and there borders. Here, I think, the other problem: when the 
block has "margin-bottom" value, it looks for something to move, even if there 
is enough space under it. And this process goes on untill "something to move" 
is found.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Are we doing margin collapsing before applying min-height or something?  If I
use height instead of min-height, the bug goes away...

Comment 6

[Boris Zbarsky [:bzbarsky]]

And indeed, we do the margin-collapsing calculation before we apply min-height.
 I think we should just zero out the mCarriedOutBottomMargin if our height
increased due to min-height, just like we would if our value of "height" were
big enough.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Like this?

Comment 8

[Hixie (not reading bugmail)]

'min-height' only affects margin collapsing in two cases:

  1. If an element has a min-height that affects its height (i.e. the min-height
     took effect), then it doesn't collapse its bottom margin with its last 
     child's bottom margin.

  2. If an element has a non-zero min-height, then it is never self-collapsing.

This is defined at the end of 8.3.1.

In the demo attachment (I wouldn't call it a testcase as it has no pass
criteria), the behaviour when the font-size is shrunk so that the #content block
border edge is shorter than 250px is that the #main and #sign elements should
touch (no non-zero margins collapse). When you increase the font-size such that
the #main block no longer uses 'min-height' to increase in height beyond
#content's height (i.e. when #content's border edge height is exactly equal to
or greater than 250px) then the bottom margin of #content collapses with the top
margin of #sign.

Does this answer your question?

Comment 9

[Hixie (not reading bugmail)]

(Oh, and yes, this does mean there is a discontinuity in the margin collapsing.
You never "half-collapse" a margin that is partially overflowing out, it's
either collapsing or not.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yep, that answers my question.  Sounds like my patch is correct (assuming that
for cases when max-height affects the height we also want to not collapse with
the child's bottom margin).

Comment 11

[Hixie (not reading bugmail)]

Yeah, guess we'll have to update the spec to handle max-height too.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 190920 [details] [diff] [review]
Like this?

Requesting 1.8b4 approval.  This should be pretty safe, and gives us parity
with other browsers in addition to making us follow the spec.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fixed

Comment 14

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050802
Firefox/1.0+ ID:2005080215

I don't know if this is expected; apologies if it is. But with the testcase, if
you increase the size of the font with CTRL++ then the gap appears again.

Comment 15

[Boris Zbarsky [:bzbarsky]]

The gap should be there if and only if the blue and red boxes have the same
height.  This will happen any time the font is big enough, of course.