Given:
<body>
<div id="fixed">
Fixed div
</div>
<div id="nonfixed">
<p>Non-fixed div</p>
<p>Non-fixed div</p>
<p>Non-fixed div</p>
</div>
</body>
And:
* { box-sizing: border-box; }
body {
margin: 0;
padding: 0;
}
#fixed {
position: static;
width: 100%;
border: 3px solid #f00;
}
#nonfixed {
margin-top: 50px;
border: 3px solid #00f;
}
Note that position:static, this gives the expected result (fiddle):
However, change position:static to fixed, and you get this (fiddle)
Even though the #fixed div is not inside #nonfixed, it has taken on the top margin of #nonfixed. This happens in both Chrome and Firefox. Curiously, the dev tools in both browsers do not show the #fixed div having any margins, so clearly it's being positioned as if it was fixed inside the #nonfixed div.
If I add top:0 to the #fixed ruleset the div goes back to the top of the window, but shouldn't this appear at the top (i.e. where it would in normal flow, but without affecting other elements) in the absence of a top specification?
For completeness: position:relative produces the same result as static and absolute looks the same as fixed.
I cannot find anything in the spec that directly addresses why an absolutely positioned element should be positioned relative to a subsequent sibling. In fact, reading the spec I find (emphasis mine):
10.6.4 Absolutely positioned, non-replaced elements
...
If all three of 'top', 'height', and 'bottom' are auto, set 'top' to the static position and apply rule number three below.
...
'height' and 'bottom' are 'auto' and 'top' is not 'auto', then the height is based on the content per 10.6.7, set 'auto' values for 'margin-top' and 'margin-bottom' to 0, and solve for 'bottom'
This seems to indicate the #fixed box should indeed be at the top of the viewport.
Since both FF and Chrome do the same thing I'm guessing it's supposed to work this way, but I'd like to know why. Can anyone explain this behavior in terms of the spec?
You'll notice that the "fixed" div is actually at the top of the body, the position and size of which match those of the "nonfixed" div.
This is most certainly due to the top margins of the body and div#nonfixed collapsing. See http://www.w3.org/TR/CSS21/box.html#collapsing-margins
8.3.1 Collapsing margins
In CSS, the adjoining margins of two or more boxes (which might or
might not be siblings) can combine to form a single margin. Margins
that combine this way are said to collapse, and the resulting combined
margin is called a collapsed margin.
(...)
Two margins are adjoining if and only if:
both belong to in-flow block-level boxes that participate in the same
block formatting context
no line boxes, no clearance, no padding and
no border separate them (Note that certain zero-height line boxes (see
9.4.2) are ignored for this purpose.)
both belong to vertically-adjacent box edges, i.e. form one of the following pairs:
top margin of a box and top margin of its first in-flow
(...)
The topis relative to the containing block, which is apparently not bodybut html (the root element).
Related
Update 2020: the below behavior is no more visible in the recent browsers
Let's start with the following situation:
html {
background: red;
}
body {
margin: 0;
min-height: 100vh;
background-color: green;
}
div {
min-height: 50px;
background-color: pink;
margin-bottom: 50px;
}
<div></div>
The body is defined with a min-height:100vh and we have a scroll bar that allow us to see the html. Here we are having a margin-collapsing, the margin of the div is collapsed with the body margin and thus create this space after the body and the scroll bar.
If we refer to the specification we have this case:
Two margins are adjoining if and only if:
...
bottom margin of a last in-flow child and bottom margin of its parent
if the parent has 'auto' computed height
the div is the last in-flow element and body has height auto as we only specified min-height.
Now let's add more elements that may be affected by this margin and keep the rules of margin-collapsing. The only way to do this is to add floated elements to keep our div always the last in-flow element.
Here is the new code:
html {
background: red;
}
body {
margin: 0;
min-height: 100vh;
background-color: green;
}
div {
min-height: 50px;
background-color: pink;
margin-bottom: 50px;
}
.l {
width:45%;
height:50px;
float:left;
margin:0;
}
.r {
width:45%;
height:50px;
float:right;
margin:0;
}
<div></div>
<div class="l"></div>
<div class="r"></div>
As we can clearly see, we still have margin collapsing (because of the scroll) AND the floated elements are also pushed down by the same amount of the margin.
So my question is: why such behavior?
My understanding of margin-collapsing is that at the end we will have only one margin applied somewhere. By adding new elements, I am expecting to have one of this two situations:
Adding the floated elements will somehow cancel the margin-collapsing (this cannot be the case as we are not breaking any rule)
The floating elements will not get affected by the margin as this one collapsed with body margin and thus moved/applied to the body. (This is a logic case for me)
In the specification I also found this complex statement:
Note that the positions of elements that have been collapsed through
have no effect on the positions of the other elements with whose
margins they are being collapsed; the top border edge position is only
required for laying out descendants of these elements.
I understand from the above that the other elements get not affected by the margin-collapsing and thus keep their initial position which explain why the floated elements are pushed down. (I am not sure if this is the case by the way)
If this is the explanation then it's a bit confusing and illogical for me. I added one margin and I end up having two margins that are clearly visible?
So why such behavior? Or maybe I missed something in the specification and we are facing more than a simple margin-collapsing?
Important notice: Before answering, please note that I am not looking for a fix to this or how to avoid this. I know at least 5 ways to cancel margin-collapsing (padding, overflow, border, flexbox,etc..).I am looking to understand why such thing happen.
For the reference: this started by this question where #Alohci highlighted this in my answer and after few comments we both didn't get convinced
Before I start, the issue of scrollbars being rendered in all browsers but Firefox is a separate issue from what is being asked about here. Firefox does not collapse margins between a parent element and its children when the parent's min-height results in the margins not being adjoining. It's also a known spec violation in Firefox that's being worked on and yet to be fixed.
Now, on to the issue at hand. From section 9.5.1 (on floats):
A floating box's outer top may not be higher than the top of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.
The last sentence in this quote is awkward, but "the rules" refer (and link) to the definition of collapsing through. While the specific text that you cite from that section is relevant, it doesn't explain why the floats respect the margin of the in-flow div.
This does:
If the top and bottom margins of a box are adjoining, then it is possible for margins to collapse through it. In this case, the position of the element depends on its relationship with the other elements whose margins are being collapsed.
[...]
Otherwise, either the element's parent is not taking part in the margin collapsing, or only the parent's bottom margin is involved. The position of the element's top border edge is the same as it would have been if the element had a non-zero bottom border.
Note the last sentence. Having a non-zero bottom border cancels margin collapsing, as you know. This means that the floats are positioned as if the bottom margins of the in-flow div and the body element did not collapse, resulting in the floats appearing to respect the bottom margin of the in-flow div.
How do I tell that the floats specifically respect the bottom margin of the in-flow div and not the collapsed margin? By giving body a larger bottom margin than that of the in-flow div and observing that it does not affect the position of the floats:
html {
background: red;
}
body {
margin: 0;
margin-bottom: 100px;
min-height: 100vh;
background-color: green;
}
div {
min-height: 50px;
background-color: pink;
margin-bottom: 50px;
}
.l {
width:45%;
height:50px;
float:left;
margin:0;
}
.r {
width:45%;
height:50px;
float:right;
margin:0;
}
<div></div>
<div class="l"></div>
<div class="r"></div>
If I have a container with an element inside that has a margin, that elements margin will not push it down within that container but instead push down the container itself. That alone, while annoying, might just be how the w3c decided it would work. But the weird thing is, if I add a border to the container that element will now be pushed down within the container and the container will then be flush against the element above (what I want). Until now most of the containers I use have had borders so that I could tell how everything was lining up, but now that I have decided to start adding background-colors and removing margins to make everything look nicer I am running in to a ton of issues with gaps between containers that have neither of the containers background colors applied to them.
In case I was not clear I created a jsfiddle to demonstrate the issue, as you can see by looking at the html / js clicking the button only toggles the existence of a border and nothing else. Yet all the margins between the containers change based on whether or not the border is there.
http://jsfiddle.net/Tysonzero/p5fgjmrn/
HTML:
<div class="first-div">
</div>
<div class="second-div">
<div class="inner-div">Test</div>
</div>
<button onclick="toggle()">Toggle Border</button>
CSS:
*
{
box-sizing: border-box;
margin: 0;
padding: 0;
}
.first-div
{
background-color: red;
min-height: 50px;
}
.second-div
{
background-color: blue;
min-height: 50px;
}
.inner-div
{
margin: 10px;
text-align: center;
}
JS:
toggle = function() {
if (document.getElementsByClassName('second-div')[0].style.border) {
document.getElementsByClassName('second-div')[0].style.border = "";
}
else {
document.getElementsByClassName('second-div')[0].style.border = "1px solid";
}
};
I want it to always work the way it works WITH a border as IMO that makes a ton more sense, and for my project it is what I need. I really hope I don't have to do something hacky such as add a 1px transparent border to everything and compensate for it when necessary. I have tried using overflow: auto; or overflow: hidden. But neither are the same as having a border. overflow: auto; will sometimes create scrollbars if the element inside is bigger than the parent or if you are using negative margins in a certain way whereas adding a border does not, overflow: hidden; completely prevents scrolling whereas adding a border does not.
Does anyone know how I can force the browser to treat everything as though it has a border (or at least make issues like this not happen) and also can anyone explain this behavior? It seems unintentional but I could be wrong.
The specific answer to your question is collapsing margins and is part of the W3C's BOX MODEL specifications:
Vertical margins may collapse between certain boxes:
Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths. In the case of negative margins, the maximum of the absolute values of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the absolute maximum of the negative adjoining margins is deducted from zero. Note. Adjoining boxes may be generated by elements that are not related as siblings or ancestors.
Vertical margins between a floated box and any other box do not collapse (not even between a float and its in-flow children).
Vertical margins of elements that establish new block formatting contexts (such as floats and elements with 'overflow' other than 'visible') do not collapse with their in-flow children.
Margins of absolutely positioned boxes do not collapse (not even with their in-flow children).
Margins of inline-block elements do not collapse (not even with their in-flow children).
If the top and bottom margins of a box are adjoining, then it is possible for margins to collapse through it. In this case, the position of the element depends on its relationship with the other elements whose margins are being collapsed.
If the element's margins are collapsed with its parent's top margin, the top border edge of the box is defined to be the same as the parent's.
Otherwise, either the element's parent is not taking part in the margin collapsing, or only the parent's bottom margin is involved. The position of the element's top border edge is the same as it would have been if the element had a non-zero bottom border.
An element that has had clearance applied to it never collapses its top margin with its parent block's bottom margin.
Note that the positions of elements that have been collapsed through have no effect on the positions of the other elements with whose margins they are being collapsed; the top border edge position is only required for laying out descendants of these elements.
Margins of the root element's box do not collapse.
So, when you add a border, you're doing exactly what the specification says, therefore you have no margin.
There are many ways and fixes and hacks to solve this, but to me, the most direct and easy is as simple as to apply an overflow:auto; property to the div you want to clear the margin.
Thus, in your CSS, you would only need to change it like this:
.second-div
{
background-color: blue;
min-height: 50px;
overflow:auto;
}
I forked your fiddle with even more border so you can notice the effect and see how good it works
I'm testing some css styles on a blog-like div layout. I used div{border: 1px solid black;} to see the divs and look at its positions.
When this line is in my style, it looks right, but I don't want to have the borders (just had it for development).
As soon as I comment it out everything changes it's positions. Why is this so?
JSFiddle Link
div{border: 1px solid black;} /* Comment this to see the problem */
body{ text-align:center; }
.postTabs{
float:left;
background-color: #c8c8c8;
width: 60px;
height: 38px;
padding: 27px 5px 5px 5px;
border-radius: 50%;
}
.postContent{
padding: 15px 15px 15px 50px;
margin-left: 35px;
margin-top: 36px;
text-align: left;
background-color: #a7a7a7;
}
<div class="postContainer">
<div class="postTabs">asdf</div>
<div class="postContent">
<div class="postBody">adf</div>
</div>
</div>
This is because of collapsing margins:
8.3.1 Collapsing margins
In CSS, the adjoining margins of two or more boxes (which might or
might not be siblings) can combine to form a single margin. Margins
that combine this way are said to collapse, and the resulting combined
margin is called a collapsed margin.
Also the spec states:
Two margins are adjoining if and only if:
both belong to in-flow block-level boxes that participate in the same block formatting context
no line boxes, no clearance, no padding and no border separate them (Note that certain zero-height line boxes (see 9.4.2) are ignored for
this purpose.)
both belong to vertically-adjacent box edges, i.e. form one of the following pairs:
top margin of a box and top margin of its first in-flow child
bottom margin of box and top margin of its next in-flow following sibling
bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
top and bottom margins of a box that does not establish a new block formatting context and that has zero computed 'min-height', zero
or 'auto' computed 'height', and no in-flow children
In this case, the first child is floated to a side and it is removed from normal flow. Hence the first in-flow child of the .postContainer container is .postContent element which has a margin-top of 36px.
Since the container doesn't establish a block formatting context, and there's no border, padding between them, the margins would be collapsed into one.
You could prevent that by giving the container:
A padding-top of 1px - for instance - Example here.
A border-top of 1px solid transparent Example here.
An overflow of anything other than visible which creates a new block formatting context - Example Here.
For further info you could refer to the spec.
Check the fiddle here
JS Fiddle
it was happening because of float:left for .postTabs class
.postContainer{
clear: both;
float: left;
width: 100%;
}
This is because of the default box model in CSS. The element is as wide as the width, plus any padding, plus any border.
You may have expected the border to sit inside of the element, but it actually makes it wider (by 2px in your case) and taller (again by 2px).
You can adjust your width and height accordingly, or you can change the box-model being used with the CSS box-sizing: border-box;
In your case, though, you are only applying the border for development purposes, so changing your CSS to support the border will mean changing it all back again later.
Rather than do all that work, use your browser tools. The screenshot below shows the browser tools in Firefox (all browser have similar tools to this). When you highlight the element in the HTML shown in the tools, it shows the outline of the element on the actual page.
This gives you your development view whenever you need it without having to change the code.
This question is similar to this one (with an excellent answer), although mine doesn't pertain to float issues.
I recently ran into some trouble when trying to apply a margin to an only-child of a block-level element:
#parent {
background: rgba(255, 0, 0, 0.1);
}
#child {
margin: 30px 0;
padding: 20px;
background: rgba(0, 255, 0, 0.1);
}
<div id="parent">
<div id="child">Foo</div>
</div>
Although the margin is applied, the parent's background is not. This remains true unless siblings are added before and after the #child, or (more interestingly in my opinion), an overflow of any value other than visible is set. Here is the same example but with an overflow value:
#parent {
background: rgba(255, 0, 0, 0.1);
overflow: auto;
}
#child {
margin: 30px 0;
padding: 20px;
background: rgba(0, 255, 0, 0.1);
}
<div id="parent">
<div id="child">Foo</div>
</div>
From CSS2.1 Section 9.4.1 - Block Formatting Contexts, I found the following:
Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.
I'm really struggling to understand the rationale behind the "overflow other than visible" logic in this instance. The margins are seemingly not being clipped in this situation, as the only thing to change is the background. Could someone demonstrate why a value of overflow: visible creates such a situation?
As I have covered in my answer to the question that you link to, the main reason overflow values other than visible result in a new block formatting context is due to implementation limitations relating to floats, even though the concept of overflow does not immediately appear to have a relationship with floats.
While the relationship between floats and collapsing margins is pretty simple (it never occurs), the fact that margins cannot collapse through the boundaries of an element with such a value for overflow either is little more than a side effect of this change, because margins are defined not to collapse through any box that establishes a block formatting context, as described in section 8.3.1. I quote:
Margins of elements that establish new block formatting contexts (such as floats and elements with 'overflow' other than 'visible') do not collapse with their in-flow children.
This includes both floats and elements with such a value for overflow. The overflow itself does not actually have any direct effect on the margins.
When both the parent and the child are block-level elements that participate in the same block formatting context, they will collapse by default unless there is something in the way:
The top margin of an in-flow block element collapses with its first in-flow block-level child's top margin if the element has no top border, no top padding, and the child has no clearance.
The bottom margin of an in-flow block box with a 'height' of 'auto' and a 'min-height' of zero collapses with its last in-flow block-level child's bottom margin if the box has no bottom padding and no bottom border and the child's bottom margin does not collapse with a top margin that has clearance.
This explains why the parent's background does not extend until you try and block the margin collapse.
In your first examples the top and bottom margins of parent and child are collapsed. Roughly speaking, the 30px margin of child is combined with the zero margin of parent, the greater margin of the two is applied on the parent. Quote:
In CSS, the adjoining margins of two or more boxes (which might or
might not be siblings) can combine to form a single margin. Margins
that combine this way are said to collapse, and the resulting combined
margin is called a collapsed margin.
In the same document, the effect of overflow (as in your second example) is explained:
Margins of elements that establish new block formatting contexts (such
as floats and elements with 'overflow' other than 'visible') do not
collapse with their in-flow children.
This clarifies an issue I've occasionally had with heights. It looks like the height of the parent element is not being calculated from the margins of the child.
Adjusting your fiddle: http://jsfiddle.net/u6tQj/2/
#parent { background: #555;}
#child { margin:200px; background: #ccc; }
The margins are being applied to the child, but the height of the parent was unaffected. Adding overflow or border causes the height to adjust. I do sometimes struggle with why parent elements don't always expand to contain the children.
It seems very odd, but...
It could be complicated to have conflicting rules on parent height. It would affect many of the browser layouts, such as parent position relative with children set to absolute, or overflow auto/hidden, and probably a host of other layout algorithms. I imagine it would unnecessarily complicate the browser's layout engine, in the same way that css selector specificity can sometimes be a major pain for us.
You would add padding to the parent to adjust its height, which is more intuitive (isn't it?).
This might be due to margin collapsing and I know about margin collapsing, at least how it affects adjacent elements, but I don't understand how it works on nested elements when negative margins are involved.
For example, in this markup and accompanying CSS:
Markup
<div class="parent">
<div class="child">
Child 1
</div>
</div>
<div class="parent">
<div class="child negative">
Child 1
</div>
</div>
CSS
body {
background: white;
padding: 45px;
}
.parent {
border: 1px solid black;
margin-bottom: 10px;
}
.negative {
margin-bottom: -1px;
}
Live example here.
When I inspect the height of the second .parent div, I notice it is 1 pixel less than the first one. This has happened because of the negative margin on the .negative element inside it. I had a quick look at W3C and couldn't find an explanation for this behavior.
Could someone please explain what's happening here and also provide me with a link to the W3C spec section about it?
This might be due to margin collapsing and I know about margin collapsing, at least how it affects adjacent elements, but I don't understand how it works on nested elements when negative margins are involved.
Section 8.3.1 has all the details. It also covers the behavior of adjoining margins between nested boxes, as well as negative margins.
However, what you're seeing here is not the effect of margin collapse because you have negated it with a border: 1px solid black declaration in your .parent rule. That means having a border there prevents your .parent margin from collapsing with your .child.negative margin altogether.
Rather, this is simply how negative margins work. This is covered in various sections of the visual formatting model, but it's most succinctly and directly addressed in the beginning of Section 11, which summarizes it thus:
Generally, the content of a block box is confined to the content edges of the box. In certain cases, a box may overflow, meaning its content lies partly or entirely outside of the box, e.g.:
...
A descendant box has negative margins, causing it to be positioned partly outside the box.
So what's happening here, instead, is:
The absolute value of the .child.negative element's negative margin is subtracted from the .parent element's actual height (by 1px).
As a result, the .child.negative element itself overflows .parent (because its own height is not changed and the default overflow for any div is visible).
Since margin collapse does not take effect here, the margin-bottom: 10px in your .parent is unaffected. Note that while any subsequent elements in normal flow will be shifted up by 1px, this is mainly due to the negative margin of your .child.negative element; in other words, a side effect of step 1.
And that's all there is to it.
when you are using .negative { margin-bottom: -1px; } then it will moved at the top. see this example.
please refer the following link you understand easily.
http://coding.smashingmagazine.com/2009/07/27/the-definitive-guide-to-using-negative-margins/
body {
background: white;
padding: 45px;
}
.parent {
border: 1px solid black;
margin-bottom: 10px;
min-height: 30px;
}
.negative {
margin-bottom: 20px;
}
conclusion:
For e.g. In your case i have to added min-height:30px to parent class so that it remains fix. if moved only if you add positive margins to negative class. It just because you can see results in above figure that tells all what you need is.
see the cssdesk link click here cssdesk
Hope, it will helps you. Cheers. !!
Margins of first and last elements will apply to outer element when the outer element doesn't have border, padding and content, instead of it self.
In your case, parent node has border, so margin collapsing won't apply in this case. As you have margin-bottom = -1px for the child node inside, when calculate the outer height of the child node will be the height of its content + padding + border-width + margin. So it will be 1px less when measuring from outside. That's why the height of parent node will be 1px less than the upper example. To see it more clearly, you may apply a background to the child node, say yellow, you will find that the child node will overlap the border of the parent node.
But if you remove the border of the parent node, it will be a total different situation.
For instance to explain margin collapsing, say you have
<div style="background-color:black">
<div style="height:10px; background-color:white; margin-top: 10px"></div>
</div>
You will not see a black box of 10px height, as the outer node will be considered to have a 10px margin on top, and the inner one's margin is ignored. And for negative situation, the outer margin will decrease.
Quote from spec:
When two or more margins collapse, the resulting margin width is the maximum of the collapsing margins' widths. In the case of negative margins, the maximum of the absolute values of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the maximum of the absolute values of the adjoining margins is deducted from zero.
For more info:
https://developer.mozilla.org/en-US/docs/CSS/margin_collapsing