Closed Bug 295309 Opened 19 years ago Closed 19 years ago

[FIXr]Parent block gets margin from child


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






(Reporter: smokemaker, Assigned: bzbarsky)



(2 files)

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:
	width: 100px; background-color: red; margin-bottom: 0;
 min-height: 250px; 
	width: 80px; background-color: blue; margin-bottom: 20px;
	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
<!--	&nbsp; -->
<div id="sign">
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
Serge, can you attach a testcase that shows this behaviour?
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 "&nbsp;" and see it)
Dupe of/related to bug 292295?
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.
Are we doing margin collapsing before applying min-height or something?  If I
use height instead of min-height, the bug goes away...
Assignee: general → nobody
Severity: minor → normal
Component: General → Layout: Block and Inline
Ever confirmed: true
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: general → layout.block-and-inline
Hardware: PC → All
Version: unspecified → Trunk
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.
Attached patch Like this?Splinter Review
Attachment #190920 - Flags: superreview?(roc)
Attachment #190920 - Flags: review?(roc)
'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?
(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.)
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).
Yeah, guess we'll have to update the spec to handle max-height too.
Attachment #190920 - Flags: superreview?(roc)
Attachment #190920 - Flags: superreview+
Attachment #190920 - Flags: review?(roc)
Attachment #190920 - Flags: review+
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.
Attachment #190920 - Flags: approval1.8b4?
Assignee: nobody → bzbarsky
Priority: -- → P3
Summary: Parent block gets margin from child → [FIXr]Parent block gets margin from child
Target Milestone: --- → mozilla1.8beta4
Attachment #190920 - Flags: approval1.8b4? → approval1.8b4+
Closed: 19 years ago
Resolution: --- → FIXED
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.
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.
You need to log in before you can comment on or make changes to this bug.