Margin Behavior of "Overflow:Hidden" Div After Floating Div on Webkit

Margin behavior of overflow:hidden div after floating div on webkit

I was able to reproduce this on Chrome for Mac, 17.0.963.56.

The problem stems from the fact you've given #brief and #list a height, but haven't contained the float. There actually isn't a double margin; the margin-right of 10px is combining with .intro's 10px padding-right to give the allusion of a 20px double-margin.

All things considered, the fact the WebKit (Chrome's & Safari's renderer), rendered things that way is a little strange.

Everything worked as expected with this CSS (see the Fiddle):

.intro {
    margin: 0 0 20px;
    padding: 20px;
    background: #FFA;
    overflow: auto;
    height: 100%;
}
.brief {
    background: rgba(255, 0, 0, 0.25);
    width: 150px;
    float: left;
}
.list {
    background: rgba(0, 0, 255, 0.25);
    margin: 0 0 0 170px;
}

CSS height:0 and overflow:hidden with margin has a different behavior on safari

My work around this was to instead of setting the height:0px, replace it with a small value such as height:0.01px and it produces a uniform results across the browsers i used test. But I hope someone has a better solution.

IE8. overflow hidden + min-width: is there a workaround to this strange behavior?

It seems that adding display: table-cell to .B makes it behave. I did not fully test in all other browsers to see if it would cause an issue. It might be best to just have it set for IE8 (though it did not seem to affect IE7/9 or Firefox).

CSS floating left weird behavior

Just set:

.short-movie {
  height: 275px;
}

To make all movie items be of the same height and stop them being affected by the previous elements height.

Floated div jumps down in a fluid layout at certain window widths

Problem solved. Strangely, it the original image was 639px instead of 600px wide. All the images were resized in the CSS, but since it was an uneven number, that may have caused problems.

Why does overflow property impact element size and flow?

According to definition "If the container element is itself contained by something else, the floated div will sit on the right margin of the container."

Case 1: The .container is covering the total space available. The .content is taking all the space except the .float(the .content is not of shape rectangle here), that's what floating is. Its actually overflowing to cover the space. Its the default behaviour.

Case 2: Now you tell the .content to hide the overflow. So it hides the overflow it was earlier doing as a default behaviour.

Case 3: You tell the .content to take the full width of the parent, i.e. .container, so it ignores the overflow:hidden and just expands to fill the space.

If you are wondering the weird behaviour of overflow:hidden, check this ARTICLE

firefox not responding to float with overflow:hidden

I wish I would know why, but add the code as follows seems to be working.

li {
    display:inline-block; /*or inline-table*/
}

Updated Demo: http://jsfiddle.net/bt0c252z/

Why there is an unintended margin-right in Safari5?

This seems indeed to be a bug in older Webkit versions. I found another question about the same issue.

There are workarounds. The most obvious is to avoid overflow: hidden to clear floats, and to use clearfix instead.

Since nobody answered to my questions, I try to give them myself:

Is this a Safari-5-Bug?

It's a Webkit Bug

If it is a Bug, does it have a name, with which I can google some workarounds?

No name found, apparently there are not many people who layout websites as I do... (and still want to support old browsers).

Can I detect somehow, which Browsers are affected with this behaviour, to define some exception rules for them.

If you really want to define exceptions, you can make such ugly things in JavaScript

var webkitCheck = /AppleWebKit\/([0-9.]+)/.exec(navigator.userAgent);
if (webkitCheck) {
    var webkitVersion = parseFloat(webkitCheck[1]);
    if (webkitVersion < 535) {
        jQuery('html').addClass('oldWebkit');
    }
}

< 535, because 534.59.10 is the Webkit version of the latest Safari5 version, and in Safari6, this bug does not occur anymore.

But thanks, @Era and @NoobEditor for your comments.

---

Related Topics