Wow, this really evolved and I learned serveral new things. May I ask why do this
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
margin:0;
padding:0;
as opposed to simply
* {margin:0;padding:0;}
Your right, the specs don’t define those as default values but it does say that the “viewport” is the [URL=“http://www.w3.org/TR/CSS2/visudet.html#containing-block-details”]initial containing block for position:fixed elements. That is why Opera gets it right on the initial page load without needing to set RP or 100% height on the body/html.
Even with that though Opera still has the resizing issue - until you specify height:1%; on one of it’s child elements. The problem with that is both position:absolute and position:fixed report their height, so the holly hack is OBEYED. (the last thing we need). You can get around that being a problem by either putting it in using generated content (which I hate the idea of, but whaddaya gonna do?) or a sandbag element (even worse, basically we’re talking a clearing DIV) - or… display:inline-block; - magically makes height behave as min-height in most standards compliant browsers (damned if I know why)…
Ironically that was the fix for the IE8 min-height bug with stick footers. Setting height:1%; on a wrapper:after block forced IE8 to look to the parent and confirm it’s height. Yeah, it is spooky that IE and Opera have so much in common. They share a lot of the same problems with each new release, makes me think that the Presto Engine is running on Trident Pistons.
As we all know the problem here is that Opera does not reflow/redraw the page. But why did it work without all your body/html fixes in Opera 9?
NOT that I consider that deployable code in the first place since IE6 chokes on it… AND there’s a reason I would NEVER bother trying to use position:fixed (or fixed anything) in the first place, much less top and bottom at the same time. (hell, it pisses me off when there’s more than one scrollbar on screen at the same time - I just consider that bad design)… I also cannot fathom what the devil you are wasting time on that float for, or how the content is even being pushed over (apart from the fact that on narrow displays it DOESN’T and goes UNDER the fixed element) - just TRYING to make it break or something?
Also wondering what the devil was up with the heading abuse in your original and the pointless floats. I think the differences in how we approach layout (since I used a extra DIV to make sure the content did NOT go under the sidebar) have something to do with that.
I know all about IE6’s lack of support for fixed positioning and that is totally unrelated to this. Don’t worry about all the heading abuse, it was just used to size the text in this test case. The floated h tags were given a width, that’s how the content was pushed over.
Still though - it’s REALLY bad when the Holly Hack fixes something in Opera. I’ve had several cases of people complaining techniques I use don’t work in Opera, when all along it’s been my use of the Holly Hack for legacy IE that’s actually been fixing it.
Like I said, it is spooky and I have always suspected that Presto uses some of the same components that Trident does.
I would call them cousins.
Just looking at your second one there with the negative margin - what in the name of San Juan Hill is up with the heading tag abuse on those?!?
NOT that I can make sense out of what that one is even supposed to accomplish with all the unnecessary crap like the generated content clear, that the fixed height (which shouldn’t ever be done on anything with text that wraps) breaks the layout on large font machines, or why the hell .clear even needs a negative margin on it in the first place given the rendering in FF at small fonts (which I’m assuming is the correct behavior)…
Whatever that’s supposed to actually DO - MEIN GOTT it’s over-thought.
WAIT –
.float+.clear {margin:-400px 0 0 250px;}/testing with adjacent sibling selector/
Opera is obeying that, other browsers are ignoring it… Yup, that’s the beast… which is why it’s positioned in two different spots depending on the font metric. (the larger line-height putting it in the middle of the content instead of atop it).
Confirmed - Opera is the only browser that is actually OBEYING the negative margin PROPERLY - it’s the other browsers that are screwed up! Remove the negative top margin, they’re all the same… or should I say the same once you put a RESET on it thanks to the margin behavior on those paragraph and heading tags. (there’s a REASON I’d be using padding instead on those, you’re tripping collapse issues).
Silly question - which of the SIX different rendering appearances that I’m seeing across different browsers (I’m seeing different in IE 6, 7 & 8) is the one that’s actually desired on that one? I’m not seeing an opera bug here, I’m seeing broken/convoluted/over-thought code. Like someone got too clever for oneself.
The threads rayzur linked to kind-of cover it, though the resets there are a bit of overkill and aren’t so much resets, and treading into being libraries unto themselves.
That particular reset has one major failing - form elements: Aka INPUT, TEXTAREA and SELECT.
The HTML and CSS specifications do not actually SAY how form elements are supposed to be rendered or how styling like padding, border or margins are supposed to be applied! Like anything the specification is vague on the browser makers all went their own direction with it and to hell with what anyone else is doing (BRILLIANT!)
Take INPUT for example:
In Gecko based browsers there’s a small bit of 0.1 to 0.3em spacing (depending on font size it tends to shrink and grow at random) separate from the padding that you have zero control over and ignores line-height. This is of course it’s Netscape 4 legacy in action. (but gecko is a whole different engine from Netscape 4! — Sure it is… Tell me another one Josephine.)
IE puts 4px padding on them that you have ZERO control over, ignores height but instead uses line-height.
Opera treats them as if they were inline-block elements (perhaps the sanest answer I’ve heard of)
… and don’t even get me STARTED about what KHTML/Webkit handle form elements.
On top of the above spacings you have no control over, each browser has added it’s own padding value to make it appear roughly the same size in all browsers by default… and that’s the problem!
You reset the padding and instead of all browsers behaving the same way your inputs are now all different sizes in every browser! As if form elements weren’t already a royal pain in the ass to deal with… 
There are a handful of other elements with similar issues - so I prefer to just reset the margins and padding on the ones I actually plan on using that NEED IT.
Personally, I would avoid some of the monster ‘resets’ out there as they take it too far, often setting up values that don’t even effect 99% of pages, setting values you are likely to be setting to something different in the first place, etc, etc, etc… See cooper.semantics post in that first link of Rayzur’s - that’s not only absurdly bloated for nothing, that would actually BREAK form elements like inputs cross-browser, defeating the point of using a reset! (much less including unnecessary crap like clearfix and applying it using presentational classes)
This can be fixed - though first you need to pay attention to the specification:
html, body {
position:relative;
height:100%;
}
NOWHERE does the specification state those as the default values for body (I throw it at HTML too since that’s identical to the min-height codebase) and yet elements that don’t have either of those should not be reporting the value of ‘bottom’ in the first place. That it works in other browsers without that is up to each browser maker. Again, the vaguaries of the specification biting us in the backside.
Even with that though Opera still has the resizing issue - until you specify height:1%; on one of it’s child elements. The problem with that is both position:absolute and position:fixed report their height, so the holly hack is OBEYED. (the last thing we need). You can get around that being a problem by either putting it in using generated content (which I hate the idea of, but whaddaya gonna do?) or a sandbag element (even worse, basically we’re talking a clearing DIV) - or… display:inline-block; - magically makes height behave as min-height in most standards compliant browsers (damned if I know why)…
http://www.cutcodedown.com/for_others/rayzur/fixedTest.html
Works fine in IE7/newer, Opera 8.5/newer, etc, etc… of the browsers one currently should support does it bomb in IE6
NOT that I consider that deployable code in the first place since IE6 chokes on it… AND there’s a reason I would NEVER bother trying to use position:fixed (or fixed anything) in the first place, much less top and bottom at the same time. (hell, it pisses me off when there’s more than one scrollbar on screen at the same time - I just consider that bad design)… I also cannot fathom what the devil you are wasting time on that float for, or how the content is even being pushed over (apart from the fact that on narrow displays it DOESN’T and goes UNDER the fixed element) - just TRYING to make it break or something?
Also wondering what the devil was up with the heading abuse in your original and the pointless floats. I think the differences in how we approach layout (since I used a extra DIV to make sure the content did NOT go under the sidebar) have something to do with that.
Still though - it’s REALLY bad when the Holly Hack fixes something in Opera. I’ve had several cases of people complaining techniques I use don’t work in Opera, when all along it’s been my use of the Holly Hack for legacy IE that’s actually been fixing it.
NOT that I would EVER write code that would rely on either behavior one way or the other - that’s an example of thinking too hard about something simple.
It’s not that I intentionally set out to make something harder than it had to be. If on a design that required the float to be moved up more than it’s height I could use RP and all browsers would comply.
It was something that I stumbled upon when working on that quiz#30. Though a negative top margin on the float had nothing to do with the solution a huge negative top margin on the cleared element did.
We’ll just have to agree to disagree because as I see it it does exactly what it says on the box and exactly what I would expect.
It finds the top margin edge of the box (wherever that happens to be - negative or positive) and applies space above it until the element clears the float.
As you suggest (and as I mentioned) I guess it does this by manipulating the top margin to accomplish this. Whether this is right or wrong or desirable is another issue of course.
You keep saying ‘escape’ - and I guess that’s my problem with it is it’s not ‘escaping’ from anything… The clear is clearing - it provides “a space above the margin to push the content past any floats”. That’s ALL it’s supposed to do - it shouldn’t be dicking with what the margin does one way or the other and there are no extra ‘elements’ for it to be ‘escaping’ from! It’s not like the element with the clear on it is INSIDE the float… (help, help, lemme out!!!)
Negative margin should behave no differently than position:relative except for shrinking the element’s flow size. You do a clear:both; and then position:relative; top:-100px; it will move where it is rendered up… though that leaves the element in ‘flow’ at it’s original position.
When working with negative margins AND position:relative I like to picture in my head each element being two separate ‘boxes’ - one, the ‘render box’ is how/where it is ‘shown’… the other box, which I call the ‘flow box’ is where it is in flow.
Negative margins shrink the flow box, and if larger than the element’s dimension will slide the rendering box completely off it - just as position:relative moves the render box in relationship to the flow box.
If you think of it as two separate parts being manipulated, it gets easier to work with them.
The problem here though isn’t so much that as the simple question - is margin SEPARATE from what is clearing it or is it WHAT is being used to clear it? The specification clearly says “Above the margin” - that to me means separate, so it shouldn’t EVER have an effect upon what margin does. It sounds to me like the browser makers where it does behave that way took a sleazy shortcut and override margin-top for something it shouldn’t - all to avoid one extra addition (ooh)…
I mean really, is there any legitimate reason for a clear to be doing anything more than the equivalent of “element:before { height:0; width:100%; }” ???
Which means the browser that ignore it or give it a collapsing behavior? They’re the ones in error. MAYBE if it was a true collapse - but that would be even screwier.
NOT that I would EVER write code that would rely on either behavior one way or the other - that’s an example of thinking too hard about something simple.
It IS clearing the float - BEFORE the margin is applied. You can prove this by making the float be RIGHT, and NARROWER than the .clear element.
Make both of them 200px wide, float the first one right, set the second one to clear:both and margin-top:-200px;
It SHOULD if the float is cleared appear next to the first one. CLEAR should NOT be overriding margin’s behavior. Clear just means push this past the float… If the clear was being ignored…
Ok, try this in your little demo code:
.float {
float:right;
width:200px;
height:100px;
margin-top:-100px;
background:#0F0;
text-align:center;
}
.clear {
clear:both;
width:200px;
height:100px;
margin-top:-100px;
background:#1AF;
text-align:center;
}
In my mind the two elements should appear next to each-other BECAUSE of the clear. If it wasn’t clearing, they wouldn’t be next to each-other, .clear would be 100px higher than .float. The CLEAR is obeyed. Negative margins shrink the flow box but not the render box - it should go up REGARDLESS of a clear. Only thing the clear should effect is where that initial starting point is.
So you’re saying the ‘proper’ behavior is for a margin to be ignored outright after a clear - I’ve encountered that in other browsers and ALWAYS assumed it was a bug. Can you point me to that in the specification because I sure as shineola can’t find it, and frankly it’s a nonsensical behavior to have margins collapse UNDER a float on a CLEARING element!
On top of which in my experience negative margins don’t collapse. (How do you minus a minus?)
This is the same **** problem that causes people to be unable to space elements apart using margins after a float isn’t it? Oh yeah, such a desirable behavior to have a value ignored for no good reason. SCREW THAT.
Hi Paul,
Remember the multi column list quiz where Kravvitz and I both thought that it was a bug when a negative top margin on a float allowed a cleared div to escape in Opera. Simon did encourage me to go ahead and report it so I did. I had asked him to let me know what became of it but he never replied back.
http://www.css-lab.com/bug-test/opera-float-clear-margin.html
I know you explained that the float no longer had a height to it but our thoughts were that a cleared element should be cleared regardless of height or lack of due to neg margins. To this day I’m still not sure about that one because all other browsers honor the clear property, or it least they give more specificity to the clear property.
I see that nothing has changed in 10.53 with that one either.
I had also talked with G.Talbot a while back after going through his Opera bug list. He had told me that he gave up on reporting bugs to Opera and will no longer do it anymore.
I don’t what to say about it either, it is all just a big mystery and that is why everyone refers to it as the black hole. 
Yeah, the thing about that AP bug is that it is a regression, it was working in Opera 9.
Yeah, your test code is basically what I am trying to get to the bottom of. It’s not so much me saying “it is proper behavior” but rather me trying to find out what should really be happening here.
On your test case if you make the margin-top:-99px on the float then yes the cleared element wins and the top margin is ignored.
That goes back to what Paul has said all along about a negative margin equal to the floats height collapses the float completely in Opera and IE.
I just set up this reduced test case without any defined heights, but they are calculated heights with padding and font-size.
http://www.css-lab.com/lab-work/clear-test.html
In my mind: FF,Safari, and Chrome do as I would expect.
Opera and IE8 let the cleared element escape, IE8 lets the extra cleared paragraph follow the cleared div. Opera does not let the additional cleared p follow the cleared div. That extra p tag was something I just noticed about IE8.
Likewise if you set margin-top:-59px on my float it will work in Opera.
Sad when the first deployable bit of CSS3 I come across is a decade old IE innovation.
Oh, and Ray, 10.10 was buggy unstable trash anyways, kind of like 10.50 - never trust point-zero releases of Opera to do anything right.
Speaking of IE specific properties going to CSS3, overflow-y:scroll has come in handy for me several times in the past. Opera would always give overflow:scroll in place of just x or y. They did get that straightened out in 10.10 
… 10.10 puts you six months and four public releases behind.
Yeah, I was running behind a little bit. To bad Opera is too, I see that 10.53 still does not fix an AP bug that I reported to them almost five months ago.
http://www.css-lab.com/bug-test/opera10-ap-bug.html
I have always heard that the Opera bug tracking system was a black hole, which is why a lot of people don’t even report bugs to them anymore. There is no public record available and you don’t even know if the same bug has been reported by someone else.
I have always heard that the Opera bug tracking system was a black hole,
Have a word with Simon when you see him
I like opera but from day 1 it has always had a problem with re-drawing content once the page had moved or an element re-flowed (as in hover). Which is probably down to the specs in part as UA’s don’t have to reflow a page if its contents are changed by a pseudo class.
User agents are not required to reflow a currently displayed document due to pseudo-class transitions. For instance, a style sheet may specify that the ‘font-size’ of an :active link should be larger than that of an inactive link, but since this may cause letters to change position when the reader selects the link, a UA may ignore the corresponding style rule.
However, you would assume that closing the window should have the desired effect and that the page should react accordingly.
That’s you ranting about something you don’t understand just yet, the test case was spawned from Quiz #30 where the mission was to overcome another Opera bug.
You can learn more about it here in the “Solution Post”
The first post explains “The Mission”, which is just a test of CSS skills so no need to worry about it not being deployable.
Here is a revised version I put together after the quiz which shows the pseudo :before Opera fixes visible so what they are doing can be seen.
Confirmed - Opera is the only browser that is actually OBEYING the negative margin PROPERLY - it’s the other browsers that are screwed up! Remove the negative top margin, they’re all the same… or should I say the same once you put a RESET on it thanks to the margin behavior on those paragraph and heading tags. (there’s a REASON I’d be using padding instead on those, you’re tripping collapse issues).
Silly question - which of the SIX different rendering appearances that I’m seeing across different browsers (I’m seeing different in IE 6, 7 & 8) is the one that’s actually desired on that one? I’m not seeing an opera bug here, I’m seeing broken/convoluted/over-thought code. Like someone got too clever for oneself.
The point of the negative top margin on the cleared element is to show that the clear property gives more weight over any negative top margins applied to it. That was the solution to the quiz.
In my test case I did mention that all browsers gave slightly different results but everyone but Opera restrained the cleared element. As Paul explains, the negative top margin on the float has collapsed it’s height in Opera. That is where we went into two different camps on the subject, Kravvitz and I assume that the cleared element should clear the float regardless of any other styles.
James Hopkins also set up a test case and gives his thoughts on this as well. He implies that the cleared element should be cleared at all costs as well.
clear:both is what this is all about
My point exactly - the spec says ABOVE IT, not as PART OF IT.
It doesn’t say it IS a margin, it says it is added BEFORE it. Doesn’t say it should collapse into it anywhere.
I would say IE6 and Opera are not being buggy about it, I’d say everyone else is. It’s supposed to be SEPARATE that way margin is still useful.
Reading that challenge - those really are the least favorite of challenges as “not fixing the markup” is NOT FIXING the MARKUP. It’s something I try NOT to encourage in people and neither should you! It encourages the use of silver bullet fixes instead of fixing what is ACTUALLY wrong.
It’s cute as a challenge subject, but it makes people think there are ‘bugs’ in browsers that are little more than coding techniques that shouldn’t even be used in the first place.
That reliance on something that may or may not be a bug depending on one’s comprehension skills when reading the specification is something in gets people thinking on…
Back when I was first on here and you had the challenges, they were a fun diversion - but now I really would tell a LOT of your challenges to go shtup themselves and instead just fix the damned markup. ESPECIALLY any of these ones that say “Oh don’t worry about ___ browser”. It’s NOT a good mindset to be promoting.
It’s not working in Opera 10.10
I see that 10.53 is the current release, is that what you guys are using?
That works good guys.
How bout’ that, Jason is floating the LI & using CSS3.
It’s progressed a lot since post#8 
Well that didn’t work. When I was sandbagging the “b” element it left the link text meaningless with css off. 
I think I remember Eric going through all these scenarios with his spriteric nav.
I was trying to keep it at only one extra element besides the li & a.
Back to the drawing board.
I was rebuilding it too. I think I got a fully floated, functional cross browser version here.
http://www.css-lab.com/demos/sprites/vertical-sprite-2.html
the bold tags in this case might be semantically incorrect - the reason I was able to use B on mine was I left it empty, so it added no meaning.
I had the font in the b tags set to bold all along so I don’t see why that would be incorrect.
In addition to the CSS cutoff since you can’t pad the element,
If you are talking about bold text adding width it is not a problem in my case because I set a width and the float generated a block box. Anything that might to big would overflow, but it’s not too big and I set text-align center on the B tag as well.
Just redid it:
http://www.cutcodedown.com/for_others/kWolfe/template.html
Now uses one sandbag instead of two. As Paul mentioned width prevents the staircase and other whitespace drop issues - so set the overflow, width and height on the LI - then pad the devil out of the anchor so it fills the height without declaring a width or height on it, then absolute position the span over the text.
Well, that’s one less tag…
