Why doesn't "margin: auto" center an element vertically? - html

As you can see in the demo below, margin: auto; centers the blue div horizontally, but not vertically. Why not?
.box {
border: 1px solid red;
width: 100px;
height: 100px;
}
.center {
background: blue;
width: 50px;
height: 50px;
margin: auto;
}
<div class="box">
<div class="center"></div>
</div>
My question is not asking for workarounds.

As mentioned, this behavior is specified in section 10.6.2 of CSS2.1, and has remained unchanged from CSS2.
Block boxes are stacked vertically from top to bottom in normal flow. Furthermore, vertical margins may collapse, and only do so under certain circumstances (in your demo, the border on the parent element will prevent any margins on the child element from collapsing with its own). If you only have one such block box, and the height of the containing block is auto, then its top and bottom margins will be zero anyway. But if you have more than one block box in the same flow, or even out-of-flow boxes affecting the layout of in-flow boxes (in the case of clearance for example), how would you expect auto margins to resolve for those in-flow boxes?
This is why auto left and right margins are likewise zeroed out for inline elements (including atomic inlines) and floats (though horizontal margins never collapse). Inline-level boxes are laid along line boxes, and floats too obey unique layout rules.
Absolutely positioned boxes are a different story: since they are never aware of any other boxes in the same positioning context as themselves, auto top and bottom margins can be calculated for them with respect to their containing blocks without having to worry about any other boxes ever interfering.
Flexbox is also a different story: what sets flex layout apart from block layout is that flex items are by definition always aware of other flex items in the same flex formatting context, including the fact that there are none. In particular, neither can floats intrude into the flex container, nor can you float flex items to subvert this (although you can still remove a child element from flex layout completely with absolute positioning). Margins behave very differently with flex items due in part to this. See sections 4.2, 9.5 and 9.6.

Why...because the W3C spec says so.
If 'margin-top', or 'margin-bottom' are 'auto', their used value is 0.
As to the actual "why"...the query should really be addressed there.

It doesn't center the element vertically because it is a block-level element in the normal flow. Thus, the following rule applies:
If margin-top, or margin-bottom are auto, their used value is 0.
It's also worth pointing out that the rule above also applies to the following elements as well: (see points 10.6.2 and 10.6.3 for more information and conditions).
Inline replaced elements
Block-level replaced elements in normal flow
inline-block replaced elements in normal flow
Floating replaced elements
Block-level non-replaced elements in normal flow when overflow computes to visible
With that being said, absolutely positioned, non-replaced elements that don't have top, height, and bottom values of auto are an exception to this rule. The following applies from point 10.6.4:
If none of the three top, height, and bottom are auto and if both margin-top and margin-bottom are auto, solve the equation under the extra constraint that the two margins get equal values.
See the example below demonstrating how an absolutely positioned element is vertically centered using margin: auto. It works because none of the three properties top, height, and bottom have a value of auto:
.box {
border: 1px solid red;
width: 100px;
height: 100px;
position: relative;
}
.center {
background: blue;
width: 50px;
height: 50px;
margin: auto;
position: absolute;
top: 0; right: 0;
bottom: 0; left: 0;
}
<div class="box">
<div class="center"></div>
</div>
In addition, it's probably worth pointing out the following rule as well:
If one of margin-top or margin-bottom is auto, solve the equation for that value. If the values are over-constrained, ignore the value for bottom and solve for that value.
This means that if the absolutely positioned element has a margin-top value of auto and a margin-bottom value of 0 (i.e., margin: auto auto 0), the element would be absolutely positioned at the bottom relative to the parent like in the example below:
.box {
border: 1px solid red;
width: 100px;
height: 100px;
position: relative;
}
.center {
background: blue;
width: 50px;
height: 50px;
margin: auto auto 0;
position: absolute;
top: 0; right: 0;
bottom: 0; left: 0;
}
<div class="box">
<div class="center"></div>
</div>

Why doesn't margin:auto work vertically?
Actually, it does – just not for every display value.
If display is flex, margin: auto centers both vertically and horizontally.
The same applies to display: inline-flex, display: grid and display: inline-grid.
.box {
border: 1px solid red;
width: 100px;
height: 100px;
display: flex; /* new */
}
.center {
background: blue;
width: 50px;
height: 50px;
margin: auto;
}
<div class="box">
<div class="center"></div>
</div>

It's because of the actual possibility of knowing the true height of the element in which you want to center vertically in. To understand that, first think about how auto horizontal centering works. You have a div which you've given it a width (fixed or percentage). The width can be calculated to certain degree. If it's fixed width, great. If it's flexible or responsive (percentage) at least you have a range that the width will cover before it hits the next breakpoint. You take that width, minus whatever it's inside and split the remainder on both sides.
Now, with that information, how could the browser calculate the infinite amount of variations in which your div will grow vertically? Keep in mind the size of the element, wrapping of text, paddings, and responsiveness will also alter the width and force the text to wrap further, and on, and on it goes.
Is it an impossible task? Not really, has CSS spent time and effort covering this? Not worth their time, I guess.
And that is basically the answer I tell my students.
But....fret not! Bootstrap v4 alpha has figured out vertical centering!
EDIT
Sorry to edit this late but I thought you may want to consider this solutions to center vertically and it is pretty simple by making use of the calc function
<div class="foo"></div>
.foo {
background-color: red;
height: 6em;
left: calc(50% - 3em);
position: absolute;
top: calc(50% - 3em);
width: 6em;
}
See it HERE

Related

How negative margin width affect float? [duplicate]

A common trick for vertical positioning elements is to use the following CSS:
.item {
position:absolute;
top:50%;
margin-top:-8px; /* half of height */
height: 16px;
}
When seen in the metric view as in Chrome this is what you see:
However, there is no visual margin depicted when you hover over the element i.e. the margin is 'outside' the border and can be visualized. But negative margins don't show up. How do they look and what is it that makes it different?
Why is margin-top:-8px not the same as margin-bottom:8px?
So just how do negative margins work and what's the intuition behind them. How do they 'bump up' (in case of margin-top < 0) an item?
Negative margins are valid in css and understanding their (compliant) behaviour is mainly based on the box model and margin collapsing. While certain scenarios are more complex, a lot of common mistakes can be avoided after studying the spec.
For instance, rendering of your sample code is guided by the css spec as described in calculating heights and margins for absolutely positioned non-replaced elements.
If I were to make a graphical representation, I'd probably go with something like this (not to scale):
The margin box lost 8px on the top, however this does not affect the content & padding boxes. Because your element is absolutely positioned, moving the element 8px up does not cause any further disturbance to the layout; with static in-flow content that's not always the case.
Bonus:
Still need convincing that reading specs is the way to go (as opposed to articles like this)? I see you're trying to vertically center the element, so why do you have to set margin-top:-8px; and not margin-top:-50%;?
Well, vertical centering in CSS is harder than it should be. When setting even top or bottom margins in %, the value is calculated as a percentage always relative to the width of the containing block. This is rather a common pitfall and the quirk is rarely described outside of w3 docos
I'll try to explain it visually:
/**
* explaining margins
*/
body {
padding: 3em 15%
}
.parent {
width: 50%;
width: 400px;
height: 400px;
position: relative;
background: lemonchiffon;
}
.parent:before,
.parent:after {
position: absolute;
content: "";
}
.parent:before {
top: 0;
bottom: 0;
left: 50%;
border-left: dashed 1px #ccc;
}
.parent:after {
left: 0;
right: 0;
top: 50%;
border-top: dashed 1px #ccc;
}
.child {
width: 200px;
height: 200px;
background: rgba(200, 198, 133, .5);
}
ul {
padding: 5% 20px;
}
.set1 .child {
margin: 0;
position: relative;
}
.set2 .child {
margin-left: 75px;
position: relative;
}
.set3 .child {
margin-left: -75px;
position: relative;
}
/* position absolute */
.set4 .child {
top: 50%;
left: 50%;
margin: 0;
position: absolute;
}
.set5 .child {
top: 50%;
left: 50%;
margin-left: 75px;
position: absolute;
}
.set6 .child {
top: 50%; /* level from which margin-top starts
- downwards, in the case of a positive margin
- upwards, in the case of a negative margin
*/
left: 50%; /* level from which margin-left starts
- towards right, in the case of a positive margin
- towards left, in the case of a negative margin
*/
margin: -75px;
position: absolute;
}
<!-- content to be placed inside <body>…</body> -->
<h2><code>position: relative;</code></h2>
<h3>Set 1</h3>
<div class="parent set 1">
<div class="child">
<pre>
.set1 .child {
margin: 0;
position: relative;
}
</pre>
</div>
</div>
<h3>Set 2</h3>
<div class="parent set2">
<div class="child">
<pre>
.set2 .child {
margin-left: 75px;
position: relative;
}
</pre>
</div>
</div>
<h3>Set 3</h3>
<div class="parent set3">
<div class="child">
<pre>
.set3 .child {
margin-left: -75px;
position: relative;
}
</pre>
</div>
</div>
<h2><code>position: absolute;</code></h2>
<h3>Set 4</h3>
<div class="parent set4">
<div class="child">
<pre>
.set4 .child {
top: 50%;
left: 50%;
margin: 0;
position: absolute;
}
</pre>
</div>
</div>
<h3>Set 5</h3>
<div class="parent set5">
<div class="child">
<pre>
.set5 .child {
top: 50%;
left: 50%;
margin-left: 75px;
position: absolute;
}
</pre>
</div>
</div>
<h3>Set 6</h3>
<div class="parent set6">
<div class="child">
<pre>
.set6 .child {
top: 50%;
left: 50%;
margin: -75px;
position: absolute;
}
</pre>
</div>
</div>
Margin is the spacing outside your element, just as padding is the spacing inside your element.
Setting the bottom margin indicates what distance you want below the current block. Setting a negative top margin indicates that you want negative spacing above your block. Negative spacing may in itself be a confusing concept, but just the way positive top margin pushes content down, a negative top margin pulls content up.
good points already made here, but while there is lots of information about how rendering of margins is accomplished by the browser, the why isn't quite answered yet:
"Why is margin-top:-8px not the same as margin-bottom:8px?"
what we also could ask is:
Why doesn't a positive bottom margin 'bump up' preceding elements, whereas a positive top-margin 'bumps down' following elements?
so what we see is that there is a difference in the rendering of margins depending on the side they are applied to - top (and left) margins are different from bottom (and right) ones.
things are becoming clearer when having a (simplified) look at how styles are applied by the browser: elements are rendered top-down in the viewport, starting in the top left corner (let's stick with the vertical rendering for now, keeping in mind that the horizontal one is treated the same).
consider the following html:
<div class="box1"></div>
<div class="box2"></div>
<div class="box3"></div>
analogous to their position in code, these three boxes appear stacked 'top-down' in the browser (keeping things simple, we won't consider here the order property of the css3 'flex-box' module). so, whenever styles are applied to box 3, preceding element's positions (for box 1 and 2) have already been determined, and shouldn't be altered any more for the sake of rendering speed.
now, imagine a top margin of -10px for box 3. instead of shifting up all preceding elements to gather some space, the browser will just push box 3 up, so it's rendered on top of (or underneath, depending on the z-index) any preceding elements. even if performance wasn't an issue, moving all elements up could mean shifting them out of the viewport, thus the current scrolling position would have to be altered to have everything visible again.
same applies to a bottom margin for box 3, both negative and positive: instead of influencing already evaluated elements, only a new 'starting point' for upcoming elements is determined. thus setting a positive bottom margin will push the following elements down; a negative one will push them up.
A margin-top of -8px means it will be 8px higher than if it had 0 margin.
A margin-bottom of 8px means that the thing below it will be 8px further down that if it had 0 margin.
Because you have used absolute positioning, and specified a top percentage, only margin-top will affect the location of your .item object. If instead you positioned it using bottom: 50%, then you'd need margin-bottom -8px to centre it, and margin-top would have no effect.
Margin affects the boundaries of an element in terms of positioning it, either absolutely as in your case, or relative to neighbouring elements. Imagine that margin is the foundations of your element on which it sits. They are typically the same size as it, but can be made larger or smaller on any or all of the four edges.
Your CSS tells the browser to position the top of your element the margin at a point 50% of the way down the page. However, as all elements are not a single pixel, the browser needs to know which part of it to line up 50% of the way down the page. For lining up the top of the element, it uses the top margin. By default this is in line with the top of the element, but you can alter it with CSS.
In your case, top 50% would result in the top of the element starting in the middle of the page. By applying a negative top margin, the browser uses the point 8px into the element from the top (ie the line across the middle of it) as the place to position at 50%.
If you apply a positive margin to the bottom, this extends the line the browser uses to position the bottom out away from the element itself, giving a gap between it and any adjacent element below, or affecting where it is placed absolutely if positioning based on the bottom.
I wonder if this question has been answered well: how css margins work and why is it that margin-top:-5; is not the same as margin-bottom:5;?
Margin is distance from the surroundings of the element. margin-top says "... distance from surroundings as we measure from top 'side' of the element's 'box' and margin-bottom being the distance from the bottom 'side' of the 'box'". Then margin-top:5; is concerned with the top 'side' perimeter,-5 in that case; anything approaching from top 'side' can overlap top 'side' of element by 5, and margin-bottom:5; means distance between element bottom 'side' and surrounding is 5.
Basically that but affected by float'ed elements and the like: http://www.w3.org/TR/CSS2/box.html#margin-properties.
http://coding.smashingmagazine.com/2009/07/27/the-definitive-guide-to-using-negative-margins/
I stand to be corrected.
Just to phrase things differently from the great answers above, as that has helped me get an intuitive understanding of negative margins:
A negative margin on an element allows it to eat up the space of its parent container.
Adding a (positive) margin on the bottom doesn't allow the element to do that - it only pushes back whatever element is below.

Why does width:auto behave differently than height:auto?

I don't get the auto value. If applied to height it will take on the child's height, but if applied to width it will take on the parent's width.
There are no MDN posts on the auto value itself, and Google yields "100% VS auto" hits rather than "width:auto VS height:auto" hits.
For my current needs I would like an element to expand to its child's width, but in general I wish to know what is the deal with auto.
.divXS {
width: 100px;
height: 100px;
background: green;
}
.divXXS {
width: 50px;
height: 50px;
background: yellow;
}
.divSM {
width: 200px;
height: 200px;
}
#Father {
background: blue;
border: 3px solid #20295E;
}
#Mother {
background: pink;
border: 3px solid #DB6DBE;
}
#Daughter {
width: 100%;
height: 100%;
}
#Son {
width: auto;
height: auto;
}
<div class="divSM" id="Mother">
<div class="divXS" id="Daughter">
<div class="divXXS" id="grandDaughter"></div>
</div>
</div>
<div class="divSM" id="Father">
<div class="divXS" id="Son">
<div class="divXXS" id="grandSon"></div>
</div>
</div>
jsFiddle / jsBin
'auto' doesn't even always behave the same way for the width property and the height property respectively. It can have different behaviors for the width property not only depending on the element's display type, but also depending on the value of other properties for the same display type. That's why it's called 'auto' — from my answer here,
The value of said property is adjusted automatically according to the content or the context of the element.
Based on your description I'm assuming your question is in the context of block layout. Block layout consists of a series of block-level boxes stacked vertically in normal flow.
So a block container box, by default, only has to grow tall enough to contain its descendants stacked vertically. And since block-level boxes never stack horizontally in normal flow, there's no reason they can't stretch to the full width of their containing block. (They don't even need to shrink to accommodate floats in the same block formatting context, though the line boxes inside them do, but that's a separate topic altogether.)
And that's why, in block layout, an auto height is based on the total height of descendants and an auto width is based on the containing block width.

In a flexbox layout, is there a `flex-shrink: 0` declaration for the cross axis?

I want to prevent elements in a flex container from shrinking in the dimension that is not the flex-direction. The following example has <article> elements side by side in a row. When the available vertical space is reduced, these elements do not force their flex container to display a scrollbar; instead the content overflows the element boundary.
Screenshot 1 - there is enough horizontal and vertical space to display everything:
Screenshot 2 - the reduced vertical space pushes the element border up:
Screenshot 3 - vertical space further reduced, container finally gets a scrollbar:
Screenshot 4 - without flex-shrink:0, the element widths (main flex axis) will also be reduced:
flex-shrink:0 can prevent horizontal shrinking, but how can I prevent the elements from shrinking vertically?
Giving the <article> elements overflow: auto or something similar does not give the desired result (= scrollbar on the container). Ideally, the display would look like this montage:
If I knew the elements' height in advance, I could give them a min-height, but that is not always the case.
FIDDLE: http://jsfiddle.net/twdan8u8/
HTML:
<main>
<article>article<br>article<br>article</article>
<article>article<br>article<br>article</article>
</main>
CSS:
* {
box-sizing: border-box; /* not the culprit */
}
html {
height: 100%;
}
body {
position: relative;
height: 100%;
margin: 0;
background: #999;
}
main {
overflow: auto;
background: gold;
display: flex;
height: 80%;
padding: 50px 30px;
}
article {
flex-shrink: 0;
font-size: 28px;
border: 2px solid red;
margin-right: 30px;
padding: 10px;
}
As is so often the case, I found the (or rather a) solution just when I finished writing the question. Since this might help somebody else, here's what I found out:
If the flex container is given the style align-items: flex-start, element heights are not reduced and the container gets a scrollbar when necessary (assuming a suitable overflow value).
The default for this property is "stretch". It can also be set on individual flex elements using align-self. The drawback is that the elements are now no longer equally high (i.e., they don't stretch to the full available height anymore).

div with inline-block not resizing

I have two elements, both with display: inline-block, and the parent has white-space: nowrap.
When the screen is resized, the div on the right side don't resize, like this.
I'm trying to make only the blue div resize.
Full source (jsfiddle)
The structure of the html is like this:
<div class="container">
<div class="header">...</div> <!-- red -->
<div class="aside">...</div> <!-- pink -->
<article>...</article> <!-- blue -->
</div>
Relevant css:
* {
box-sizing: border-box;
}
div.container {
margin: 0 auto;
max-width: 40em;
padding: 0;
white-space: nowrap;
}
div.container > * {
white-space: normal;
}
.aside {
display: inline-block;
max-width: 15em;
vertical-align: top;
}
.article {
display: inline-block;
max-width: 25em;
}
Old question, but for the sake of knowledge of anyone who reads this and also has the doubt:
What I've found is that setting position: relative on the .container
and position: absolute on the .article does what I want.
An absolute positioned element is positioned relative to the nearest positioned ancestor, where a positioned element means anything with a position property different to static, the default; if does not found any positioned element, uses the body element.
The absolute positioned elements, if has their width and heigth in auto, resizes to fit its content, and limits the maximun sizes by its positioned ancestor. You can check this putting a short string instead a large one: the element will shrink to the length of text. If you remove the positioning from div.container, the article (if still positioned absolute) will grow (depending on its content) to cover the space between previous element and body width.
And, related to the aforementioned and to add some utility to this delayed answer, a not-very-know bonus: if you define the right and left properties of a absoluted positioned element, and leave the width in auto, the element will cover the horizontal size between the right and left defined. This way you could put something like
article {
background-color: #a0f4ec;
display: inline-block;
position: absolute;
right: 0;
left: 30%;
}
div.aside {
background-color: #faf;
display: inline-block;
max-width: 15em;
width: 30%;
}
This trick also applies in a vertical sense, but with height, top and bottom properties.
There are a few ways to do it.
Method 1:
two divs the same line, one dynamic width, one fixed
Method 2 (negative margins)
http://alistapart.com/article/negativemargins
Unfortunately, Narxx's answers require the divs to be floated. I'm sure that's what you should do if you're building a real site, but in my case, I'm trying not to use it.
What I've found is that setting position: relative on the .container and position: absolute on the .article does what I want.
Simplified fiddle
If anyone can explain why, I'll mark it as an answer.

How can I lay out two <div>s on one line, and have one centre-aligned (relative to the entire line) and the other right-aligned?

I want to display 2 divs in a single line. I have a parent div and two child divs.I want to keep the width of first child div and parent div equal. So the header(label of first child div) displays always middle position of parent div and I want to display the second child div at the right side in the same line of parent div.(Condition is always label of first child div should display middle of parent div). Here is the jsfiddle.
If I were styling this header section for a website, and I wanted some flexibility in styling the various elements, here is out I would start.
For my HTML:
<div class="head">
<div class="innerfirst">
<h1>ABCDEF GHIJ</h1>
</div>
<div class="innersecond">
<label>RIGHT1</label>
<label>RIGHT2</label>
</div>
</div>
I would put the page title in a <h1> tag so that I can adjust font-size, padding, background color and so on. In fact, you could add a tag line below the title line and various background images. Having .innerfirst and h1 gives you quite a bit of flexibility.
The <label> tags don't make sense semantically in this context, but perhaps you will have have input fields later like a search box.
For the CSS:
.head {
background-color:#2191C0;
width: 100%;
height: 85px;
position: relative;
}
The above is fine, set position: relative so that you can use absolute positioning for one of the child elements. The fixed height is a good idea, makes it easier to adjust elements vertically.
.innerfirst {
}
.innerfirst h1 {
text-align: center;
color: #FCFCFC;
padding-top: 10px; /* You could also use a margin... */
}
By default, .innerfirst will have 100% width since it is an in-flow block element, same with the h1 element. You can center the text within h1, and adjust color, padding and margin as needed.
.innersecond {
border: 2px solid lightgray;
color: white;
position: absolute;
width: 25%; /* Set this or by default it will shrink-to-fit content */
height: 61px; /* Set this or by default it will shrink-to-fit content */
top: 5px;
right: 5px;
padding: 5px;
}
What you could do is create a box of text and absolutely position it to the right. It is a good idea
to set a height and width otherwise, as a result of the absolute positioning, the div will shrink to fit the content, which is sometimes useful. The top and right offsets will position the .innersecond to the top-right of the parent container because you set position: relative in .head.
.innersecond label {
display: block; /* optional if you want block behavior */
border: 1px dotted white;
}
Finally, if you want the label tags to behave like blocks, use display: block and style according to you design requirements.
For reference, demo fiddle: http://jsfiddle.net/audetwebdesign/qpb9P/
Here's an updated jsfiddle. Read up on the display property!