CSS - Test Your CSS Skills Number 30 - Multi columns

[jameshopkins]

Rayzur asked me to take a look at the Opera issue, and have drawn up the following conclusion.

For the quiz I would say opera's behaviour is a bug as the specs on clearance state that space should be applied above the element to bring it down below the float. It is supposed find the top border edge of the element and then move that top edge down below the float.

I concur with this statement. Also, whilst determining whether this was a bug or not, I took into account how the bug is triggered; that is, the negative margin-top of the floated element must be greater than it's computed height - there must be no direct connection between these two property values, that would result in such behavior. Also, the spec definition describing the placement of spacing that's caused by clearance, implies that any margin-top value would be ignored when that element is cleared - "Clearance is introduced as spacing above the margin-top of an element..."

During the deconstruction of the test case, I happened to remove the sibling preceding (.static) the floated element (.float), which revealed a new cross-brower inconsistency; if the floated element (which has a margin-top value greater than it's computed height) is instead the first child, a negative margin-top value of the following cleared element appears to be wrongly applied to the floated element, in Opera 10, Firefox 3, & Safari 4 - in IE8, the negative margin-top value applied to the cleared element is completely ignored. Like with the Opera bug that was initially discovered, the connection described earlier between the negative margin-top value and height of the floated element is a trigger for this issue too. The problem can be fixed by establishing a top border box or top padding box on the parent.

I'm inclined to label this issue a bug because of the nature of the trigger, the nature of the fixes, and also because of the fact that it has the potential to have adverse effects to content preceding the parent element.

[Rayzur]

I took into account how the bug is triggered; that is, the negative margin-top of the floated element must be greater than it's computed height - there must be no direct connection between these two property values, that would result in such behavior.

Hi James,
Thanks for the in depth investigation of this float bug.
That was my thoughts all along when I saw that Opera was the only one making the connection between the margin and the height.

Also, the spec definition describing the placement of spacing that's caused by clearance, implies that any margin-top value would be ignored when that element is cleared - "Clearance is introduced as spacing above the margin-top of an element..."

Yes, that should obviously include negative margins as well.

During the deconstruction of the test case, I happened to remove the sibling preceding (.static) the floated element (.float), which revealed a new cross-brower inconsistency; if the floated element (which has a margin-top value greater than it's computed height) is instead the first child, a negative margin-top value of the following cleared element appears to be wrongly applied to the floated element, in Opera 10, Firefox 3, & Safari 4 - in IE8, the negative margin-top value applied to the cleared element is completely ignored.

Hmm, that is strange behavior too. Just checked it in Safari 3 and it does the same. I see why you called it "Cross Browser", they all seem to wrongly apply the margin to the float.

That is hauntingly familiar with that Mozilla Clearfix Margin Bug we just got through investigating.

The fixes are simple enough though, just your standard margin uncollapsing methods.

I'm inclined to label this issue a bug because of the nature of the trigger, the nature of the fixes, and also because of the fact that it has the potential to have adverse effects to content preceding the parent element.

That is kinda what I said in my previous post , "It is definitely enough to cause chaos."

Thanks for posting back with you final thoughts on this. I had filed a bug report with Opera after zcorpan (Simon) encouraged me to do so. I have no idea what will become of it as there is no public list of reported bugs at Opera. You probably would have spoke the language better than me but I think I still have a copy of it if you need to see how I described it.

[YuriKolovsky]

I suspect this has something to do with margin-collapse,
gotta hate it so much... i still think that margin collapse should be added by a CSS rule and Off by default, or at least Div's should not have margin collapse, or as a very minimum there should be a CSS trigger to switch it off, and then after its off it would be very likely that the above bug would disappear.

[jameshopkins]

I suspect this has something to do with margin-collapse...

I wouldn't be so sure. It's cetainly not related to the term margin collapse detailed in the specification, which describes collapsing between vertically-adjacent margins. I believe this issue is more to do with actually disabling the margin in certain instances.

...i still think that margin collapse should be added by a CSS rule...

This has already been proposed numerous times on www-style, but I believe has only been followed up in detail in the most recent proposal. However, looking back over the thread, it appears that a resolution wasn't reached, with some suggesting that creating block formatting contexts would be a better option.

Interestingly, it was reported that Webkit includes an experimental implementation of a comparable mechanism, however I can't seem to get it working. Presumably, it was removed due to concerns regarding feature adoption of such an experimental feature.

...and Off by default, or at least Div's should not have margin collapse, or as a very minimum there should be a CSS trigger to switch it off, and then after its off it would be very likely that the above bug would disappear.

By seperating these previously unchangeable mechanisms into their own properties in CSS3, the initial values of these properties must default to current CSS 2.1 behavior, to retain backwards compatibility. Authors can of course set such properties globally in their own stylesheets - which I'll be doing with the box-sizing property, for example.

[YuriKolovsky]

-webkit-margin-top-collapse:separate;

looks very nice! thanks for pointing me at it.

this is what i used with safari 4, works just fine for me (too bad other browsers don't have this).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>margincollapse test</title>
<style type="text/css">
p {
	-webkit-margin-collapse:separate;
}
</style>
 
</head>
<body>
<div>A</div>
<p>B</p>
<p>C</p>
<div>D</div>
</body>
</html>

---------
Netscape 3 used to do it before they had CSS, and when CSS was created, it had to describe that behavior so it could be implemented in CSS.