CSS Overflow Hidden Increases Height of Container

overflow:hidden on inline-block adds height to parent

I had this issue when building a horizontal slider. I fixed it with vertical-align:top on my inline-block elements.

ul {
overflow-x: scroll;
overflow-y:hidden;
white-space: nowrap;
-webkit-overflow-scrolling: touch;
}

ul&::-webkit-scrollbar {
display: none;
}

li {
display: inline-block;
vertical-align: top;
width: 75px;
padding-right: 20px;
margin:20px 0 0 0;
}

Why does overflow: hidden add additional height to an inline-block element?

The extra height is the same height as the height difference between vertical-align: baseline, and vertical-align: bottom. The "descender line". That's where the seemingly random "5 extra pixels" comes from. If the font size is 10 times as large, this gap will also be 10 times as large.

Also, it seems that when overflow: hidden is not there, the inline-block element has its baseline as the same baseline of its last line of text.

This leads me to believe that overflow: hidden forces the baseline of the entire inline-block element to be at the bottom of the element. Even though there is no text there, the parent of the inline-block element reserves space for the descender line. In the example given in the question, it cannot be easily seen since the parent of the inline-block element has height: 100%. So, instead, that extra space reserved for the descender line overflows out of that parent div.

Why is this space still there, even though there's no text? I think that's because the inline-block creates an inline formatting context, which is what causes this space. Were this element to be a block, it would only create this inline formatting context once it encounters an inline element or text.

This is just a theory, but it seems to explain it. It also explains why @Jonny Synthetic's answer works: adding overflow: hidden to the parent hides that extra descender line.

Thanks to @Hashem Qolami for the jsbins that gave me this theory.

Overflow hidden doesn't work despite having height set

By setting your .loader-overlay height to be 100%, you are telling it to occupy 100% of its parent. Being that the parent in your case is body, which does not have a set height, it will not behave as you expect.

What I would suggest is trying out CSS3 Viewport Height (vh). Something like this would set the div to the height of the viewport, which can change dynamically across devices:

height: 100vh;

This being said, your content isn't even in the div with overflow hidden, so it will add to your page's height regardless of what you do with .loader-overlay.

Can I use overflow:hidden without an explicit height somehow?

In my opinion using overflow: hidden without setting dimensions doesn't make sense. If you don't want to specify the height of the container and if your images have a fixed width you could use this solution: http://jsfiddle.net/ZA5Lm/11/

The image is positioned with absolute, taking it out of the text-flow. However - and I'm aware that this may be ugly - you need to specify a padding-left to move the text away from the image.

Make div with overflow grow and shrink until 100% of parent

I am not sure if i understand you correctly.

.layout {
box-shadow: 0 1px 5px rgba(0,0,0,.15);
}
.table-container {
height: auto;
max-height:100%;
overflow:auto;
}

Codepen

But if you want the content to define the height of an Container, just set the height to auto as default. To define the point when the scrollbar shall appear use max-height. And overflow:auto; for the scrollbar.

Why does overflow: hidden have the unexpected side-effect of growing in height to contain floated elements?

To put it most simply, it is because a block box with an overflow that isn't visible (the default) creates a new block formatting context.

Boxes that create new block formatting contexts are defined to stretch to contain their floats by height if they themselves do not have a specified height, defaulting to auto (the spec calls these boxes block formatting context roots):

10.6.7 'Auto' heights for block formatting context roots

In certain cases (see, e.g., sections 10.6.4 and 10.6.6 above), the height of an element that establishes a block formatting context is computed as follows:

[...]

In addition, if the element has any floating descendants whose bottom margin edge is below the element's bottom content edge, then the height is increased to include those edges. Only floats that participate in this block formatting context are taken into account, e.g., floats inside absolutely positioned descendants or other floats are not.

This was not the case in the original CSS2 spec, but was introduced as a change in CSS2.1 in response to a different (and much more pressing) issue. This answer offers an explanation for the changes. For this reason, it seems quite apt to call it a side effect, although the changes were very much intentional.

Also note that this is not the same thing as clearing floats (clearance). Clearance of floats only happens when you use the clear property and there are preceding floats to be cleared:

  • If you have an element with clear: both that's a sibling of the outer element in your example, the floats will be cleared but the outer element will not stretch.

  • If you have a similar element (or pseudo-element) as the last child of the outer element instead (making it a following sibling of the floats), the outer element will stretch downward in order to contain the bottom edge of that element, and for a zero-height element that essentially means the bottommost edge of the floats. This technique is known as "clearfix" because the element (or pseudo-element) has no other purpose than to force the outer element to contain the floats by way of clearance within it.



Related Topics



Leave a reply



Submit