[B]This is a thread split from an original question in the “different sized uls” thread which led to a good discussion
Spike[/B]
I’m reading these comments… It’s a fixed width layout with fixed width images - why would you need to be **** around with min-width? Not getting 90% of the issues but then - I’d never write code the way most of this seems to be done.
Is unlocked for ease of access to the gooey bits. Valid XHTML 1.0 Strict, would be valid CSS if not for a few IE and FF workarounds, (zoom:1; and -moz … big deal). Tested working IE 5.5, 6, 7 & 8, Opera 9.62 and 10.52 RC, FF 2 & 3.6, and the latest flavors of Safari and Chrome. The legacy IE support was by way of taking an axe to all the alpha transparency, so you won’t need any of that .pngfix nonsense.
Made a couple cosmetic changes, added some hover states, cleaned up some elements that I didn’t care for (like the open left border on the subboxes). Took it down from 130k of images in 29 files to 80k of images in 14 files - so a lot less handshaking involved.
I’ll write up a section by section breakdown of the markup and section by section breakdown of the CSS to go with this when I get a chance… hopefully you’ll be able to learn from my approach once I get that up here.
Hi Jason,
I understand your frustrations with the op’s code and yes I would have taken a completely different approach to the code also.
In the example you posted above you have got around setting a BG color/image on the top black bar by setting that as the BG image on the body. That’s fine, but let’s say that is not how we want to utilize the body BG property. And yes, I know a black stripe could be added to the top of any BG image but it would cause problems if it were a repeat-y image.
The reason for setting min-width on a full width header with a page that has a fixed width wrapper is to keep the header’s BG color from stopping short when a horizontal scrollbar is induced. There are times when you don’t even need to set width:100% along with the min-width value since it defaults to width:100% anyways. A lot of times width:100% is used as a haslayout trigger. In the case of a sticky footer layout with full width header & footer heights are required on them and that will take care of haslayout. Either way (with or without width:100%) a min-width is needed to keep the BG color from stopping short when the page scrolls to the side.
By the way, nice job on the recode. But it is not a sticky footer layout that mistaya was wanting.
Take this code below and run it in your browser. Then reduce the viewport width to the point where the fixed width wrapper div produces a horizontal scrollbar. Now you will see that the header/footer BG leaves a gap on the right when it scrolls left.
I have disabled the min-widths, after you view the page then enable the min-widths and you will see what it is all about.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Full Width Header & Footer</title>
<style type="text/css">
h1,h2 {
margin:0;
padding:10px 10px 0;
text-align:center;
}
p {margin:10px;}
body {
background:#E8E8F4;
font:100% arial,"trebuchet ms",tahoma;
margin:0;
padding:0;
}
html,body{
height:100%;
}
/*=== Float Containment and Bug Fixes (Do Not Alter These!) ===*/
body:before {/*Opera min-height 100% Fix (Maleika)*/
content:"";
height:100%;
float:left;
width:0;
margin-top:-32767px;/*eliminate need for inner non clearing element (Erik.J)*/
}
#wrapper:after, /* #wrapper:after for IE8 min-height:100% Fix*/
#content:after { /* #content:after for Float Containment*/
clear:both;
content:"";
display:block;
height:1%;/*fix IE8 min-height:100% bug (Erik.J)*/
font-size:0;
}
#header {
[COLOR=Red]/*min-width:800px;*/[/COLOR]
height:99px;/*100px with border*/
position:relative;
z-index:1; /*lay it on top the main wrapper*/
border-bottom:1px solid #000;
background:#959595;
font-size:.8em;
}
* html #wrapper{height:100%;} /* is "min-height" in IE6 */
#wrapper {
width:800px;
margin:0 auto;
margin-top:-100px; /* now pull it back up under header (same as header height)*/
min-height:100%;
background: #CCC;
border-left:1px solid #000;
border-right:1px solid #000;
}
#content {
padding:100px 0 60px; /*set a top and bottom padding to preserve the header and footer */
width:100%;/*haslayout*/
}
#footer {
margin:-60px auto 0; /* a negative top margin pulls the footer up into viewport*/[COLOR=Red]
[COLOR=Red]/*min-width:800px;*/[/COLOR][/COLOR]
height:59px;/*60px total (a sticky footer needs a fixed height to work properly)*/
border-top:1px solid #000;
background:#959595;
}
#footer p{
font-weight:bold;
text-align:center;
}
</style>
</head>
<body>
<div id="header">
<h1>Full Width Header & Footer<br> with Sticky Footer</h1>
</div>
<div id="wrapper">
<div id="content">
<h2>Page Title</h2>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Mauris vel magna. Mauris risus nunc, tristique varius, gravida in,
lacinia vel, elit. Nam ornare, felis non faucibus molestie, nulla augue
adipiscing mauris, a nonummy diam ligula ut risus. Praesent varius. Cum
sociis natoque penatibus et magnis dis parturient montes, nascetur
ridiculus mus. Nulla a lacus. Nulla facilisi. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Fusce pulvinar lobortis purus. Cum sociis
natoque penatibus et magnis dis parturient montes, nascetur ridiculus
mus. Donec semper ipsum et urna. Ut consequat neque vitae felis.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Mauris vel magna. Mauris risus nunc, tristique varius, gravida in,
lacinia vel, elit. Nam ornare, felis non faucibus molestie, nulla augue
adipiscing mauris, a nonummy diam ligula ut risus.</p>
</div>
</div>
<div id="footer">
<p>Footer Stuff</p>
</div>
</body>
</html>
Which is why if I wanted to use body for a background on the other axis I’d put a sandbag div (aka non-wrapping) in BEFORE #pageWrapper, set the height and then use a negative margin to ride #pageWrapper up over it.
Ah, I get it. Something I usually shrug my shoulders at - but I tend to design fully fluid or semi-fluid… if 640 wide users want to kvetch about something like that - oh well.
Didn’t see sticky footer in the original - do you mean 100% min-height? Those ARE two different things… Sticky footer is always on screen regardless of height (more trouble than it’s worth), 100% min-height layout is where if the page is shorter than the window the footer is at the bottom, but the footer is pushed off screen if the page is tall enough.
Which did he want? I didn’t find mention or code for either in the original or this thread.
Uhm, broken 100% min-height layout - But I see what you are saying about the width issue.
Code-wise - seriously, what’s with the :after nonsense… clearfix is so 2001. Add to that the :before for what position:relative on html,body would fix, the lack of a line-height or fallback family on the font declaration (NEVER trust default line height) that ‘demo’ is filled with issues.
Try this on for size - same thing but without resorting to :before or :after, and it works
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
lang="en"
xml:lang="en"
><head>
<meta
http-equiv="Content-Type"
content="text/html; charset=iso-8859-1"
/>
<title>
Full Width Header & Footer
</title>
<style type="text/css">
/* null margins and padding to give good cross-browser baseline */
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;
}
img,fieldset {
border:none;
}
html,body{
height:100%;
position:relative; /* opera bugfix */
}
p {
padding:0.5em;
}
body {
text-align:center; /* center #pageWrapper in IE 5.x */
font:normal 85%/130% arial,"trebuchet ms",tahoma;
background:#E8E8F4;
}
h1,
#footer {
position:relative;
zoom:1; /* trip haslayout */
min-width:768px;
text-align:center;
background:#959595;
}
* html h1,
* html #footer {
/* legacy IE has no min-width, so fake it with an expression */
width:expression(
(document.body.clientWidth>800) ? "auto" : "768px"
);
}
h1 {
padding:8px 0;
margin-bottom:-89px;
/*
fixed height means fixed font, otherwise breaks LF/120dpi
or higher and some handhelds 72/75dpi
*/
font:bold 32px/36px arial,helvetica,sans-serif;
border-bottom:1px solid #000;
}
#pageWrapper {
overflow:visible; /* wrap floats */
width:766px; /* also trips haslayout, so floats are wrapped in IE */
min-height:100%;
margin:0 auto;
background: #CCC;
border:solid #000;
border-width:0 1px;
}
* html #pageWrapper {
/*
IE6/earlier has no min-height, but will incorrectly treat
height as such if overflow is visible. This would break our
float wrapping except that
*/
height:100%;
overflow:visible;
}
#content {
padding:89px 0 49px;
text-align:left;
}
#content h2 {
text-align:center;
padding:0.4em;
font:bold 120%/120% arial,helvetica,sans-serif;
}
#footer {
padding:8px 0;
line-height:32px;
margin-top:-49px;
border-top:1px solid #000;
}
</style>
</head><body>
<h1>Full Width Header & Footer<br> with Sticky Footer</h1>
<div id="pageWrapper">
<div id="content">
<h2>Page Title</h2>
<p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Mauris vel magna. Mauris risus nunc, tristique varius, gravida in,
lacinia vel, elit. Nam ornare, felis non faucibus molestie, nulla augue
adipiscing mauris, a nonummy diam ligula ut risus. Praesent varius. Cum
sociis natoque penatibus et magnis dis parturient montes, nascetur
ridiculus mus. Nulla a lacus. Nulla facilisi. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Fusce pulvinar lobortis purus. Cum sociis
natoque penatibus et magnis dis parturient montes, nascetur ridiculus
mus. Donec semper ipsum et urna. Ut consequat neque vitae felis.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Mauris vel magna. Mauris risus nunc, tristique varius, gravida in,
lacinia vel, elit. Nam ornare, felis non faucibus molestie, nulla augue
adipiscing mauris, a nonummy diam ligula ut risus.
</p>
<!-- #content --></div>
<!-- #pageWrapper --></div>
<div id="footer">
Footer Stuff
</div>
</body></html>
Takes an axe to a lot of the unneccessary code… Usually if you end up resorting to :before or :after, you’re spinning your wheels over nothing. This is PARTICULARLY true of that clearfix malarkey (NOT a fan) but equally so for many unneccesary ‘opera fixes’… in this case what you were using :before to do can be easily corrected just by setting position:relative on “html,body”. (I found that one by blind luck about a year and a half ago - you know the drill, blinding throwing properties at elements until it works?)
Of course, I threw a reset on it too… and use a lot more padding than margins because collapse issues can drive you nutters. One BIG change you’ll notice is I don’t declare height on either the h1 or #footer - the reason I don’t set those is so that IE 5.x works too. (which yes, this version works all the way back to 5.5)… so much easier to just set the line-height, and let line-height + padding + border add up to the value than even think about setting the height manually.
It also WORKS as a min-height example - since yours did not. (the footer was up about twice as far as it should have been - and varied distance based on resolution and browser)
Excuse me? What would you do, if persay, the design requirement was to have osmething hanging out of a container but you needed to contain your floats? You have these to choose form
display:table (or other block contexting examples)
overflow
clearing element
clearfix
Display:table doesn’t work in IE and is hardly a suitable choice for this considering it can alter the way things appear.
overflow-not possible considering we need to have something hanging out.
clearfix-You are saying this is outdated so it’s ruled out
clearing element-add markup? Should we really add markup just to do the same thing a few lines of CSS could do? With the exact same results cross browser? If you are into making code bloated and unsemantic then go for it, I will continue using the clearfix (though I am an overflow junkie) where needed. I refuse to waste markup on clearing elements (unless it’s to counter a bug)
Didn’t see sticky footer in the original - do you mean 100% min-height? Those ARE two different things… Sticky footer is always on screen regardless of height (more trouble than it’s worth), 100% min-height layout is where if the page is shorter than the window the footer is at the bottom, but the footer is pushed off screen if the page is tall enough.
No, a “Fixed Footer” is always on screen.
A Sticky Footer is the same as min-height:100% and gets pushed down when content reaches it.
Uhm, broken 100% min-height layout - But I see what you are saying about the width issue.
Code-wise - seriously,what’s with the :after nonsense… clearfix is so 2001. Add to that the :before for what position:relative on html,body would fix, the lack of a line-height or fallback family on the font declaration (NEVER trust default line height) that ‘demo’ is filled with issues.
That sticky footer I posted is not broken nor is it filled with issues. The lack of a line-height or fallback font-family has nothing to do with the sticky footer performance.
Yours is the one that is broken, if you knew how to test a sticky footer you would see that yours fails in IE8 and Opera. View your page in those browsers then grab the bottom of the window (not the side or corner of the window) and drag it up or down. Your footer hangs!
The :after nonsense as you call it is the IE8 min-height bug fix and the :before element is the Opera fix. If you care to learn more about them you can do so here.
And by the way, where did you ever get the idea that the default of overflow:visible; is a float containment mechanism. It is either hidden or auto and they both cause problems with Opera on a sticky footer when combined with the min-height:100% element…
#pageWrapper {
[B]overflow:visible; /* wrap floats */[/B]
width:766px; /* also trips haslayout, so floats are wrapped in IE */
min-height:100%;
margin:0 auto;
background: #CCC;
border:solid #000;
border-width:0 1px;
}
It also WORKS as a min-height example - since yours did not. (the footer was up about twice as far as it should have been - and varied distance based on resolution and browser)
Lol, I had the height set at 60px and that is exactly where it was at.
Ok, so terminology conflict. Sticky to me means ‘stuck in place’.
Doesn’t render properly in any browser here. In IE6 the footer is halfway up the page over the content area, in opera it’s got about 1EM of space below it, in Firefox it has double that… and it’s forcing horizontal scrollbars in IE8 even at 1920 wide … and there’s a vertical scrollbar always present in FF, Opera and IE.
Though I’m a large font/120 dpi user - that could be screwing things up. (though that does NOT explain FF since it ignores the system metric)
I’d say that qualifies as your example not working.
Line-height certainly can have an effect in IE, where elements will grow to line-height. PROBABLY why I’m getting scrollbars in IE8 on your example. (testing… yup.)
Lack of a fallback family certainly has no effect, but it’s bad coding.
Odd, works just fine here in IE 5.5, 6, 7 & 8, Opera 9.62 and 10.52 RC1, FF 2 and 3.6, as well as the latest flavors of Safari and chrome even with my typo.
You mean the footer refresh issue? I never really sweated that one - figured if it REALLY mattered to users of the browsers that don’t render it right they could just refresh. It’s better than having the footer rendering in four different spots in four different browsers like yours did. Not sure I’d waste 15 lines of markup on fixing something that 0.0001% of users would ever come across. (especially since minimize/maximize/restore lacks that bug) - interesting to find out there’s a fix - but there’s got to be a way to clean that up somehow.
Though I was unaware that IE8 had inherited Opera’s bug on that.
My Bad - Typo, should say hidden… which is why it’s set BACK to visible and has the comment on the * HTML version. (doesn’t make much sense to set it to visible in both, no?)
Bottom line - I guess we have different definitions of ‘broken’. The little resizing issue you list I kind of shrug my shoulders “Oh well” about. I’m going to try adding that ‘fix’ and playing with it to see if it can be made leaner though… Hopefully it won’t screw up my version the way it appears to screw up yours when viewed on my machine.
– edit –
adding that ‘fix’ with :before and :after DOES screw it up badly in opera - didnae test anywhere else yet… the lack of a height declaration on it combined with Opera’s minimum font-size is the likely culprit, since clearfix and it’s kin have thrown in that extra space for quite some time (another reason NOT to use it).
Odd, works just fine here in IE 5.5, 6, 7 & 8, Opera 9.62 and 10.52 RC1, FF 2 and 3.6, as well as the latest flavors of Safari and chrome even with my typo.
No, your page breaks in Opera and IE8 just like I said it does.
Doesn’t render properly in any browser here. In IE6 the footer is halfway up the page over the content area, in opera it’s got about 1EM of space below it, in Firefox it has double that… and it’s forcing horizontal scrollbars in IE8 even at 1920 wide … and there’s a vertical scrollbar always present in FF, Opera and IE.
Though I’m a large font/120 dpi user - that could be screwing things up.
Hmm, I am not getting any of the problems you mention. IE6-8 are just fine and give no horizontal scrollbars. Opera and FF are fine on my end too.
Huh, still screwed up here… Win7 if that makes any difference.
I was going through trying to fix that scrolling issue - you know the :after IE fix appears to fix the opera bug too, so you don’t need body:before? (9.6 and 10.2)
Though neither is needed - holly hack fixes both IE and Opera if you put it on Content. Does this work for you?
Also fixed my typo - my bad I’m bedridden on the netbook at the moment, so the code might be a bit sloppy / well below my normal level of quality. (why I ended up coming back to sitepoint - needed something fresh since DP is too mercenary, and everything else is spam hell or nube city - I missed people who at least have SOME clue what they are doing). Moved the H1 into #pageWrapper so that it’s separate from the bar and inherits the single pageWrapper’s width - were that said trick was possible with the footer.
Yours does seem to have one advantage in the only browser it appears to work in for me (IE7) - it doesn’t have the ‘scrollbars both directions height is screwed up’ bug… but unfortunately that’s the only browser yours works in for me. – edit – My bad, wasn’t testing it right, IE7 doesn’t do that either way, IE6 does it both ways… --end edit – Fun too since IE8’s “IE7” rendering bears no resemblance to what IE7 is doing in XP under Sun VB. In IE7 mode IE8 won’t let me scroll yours when the window is tiny.
– edit –
Odd that height:1% is the answer for both opera and IE - I mean for IE it makes sense in terms of haslayout… when positioning is messed up haslayout the parent, when height/scrolling is messed up haslayout the child… but what that’s doing to fix Opera is beyond me… but hey, it works! Certainly a lot cleaner than all that :after and :before stuff.
Edit:
We’ll try to get this straightened out as to what is different between our OS’s and browsers.
I hate to turn the OP’s thread into a sticky footer test so it may be best to start a new thread.
I have to log out now but I will check back and see how those links above rendered for you.
First two seem to work except when the windows is shorter than the page, the top of the scrollbar is off the screen in Opera, with a black box below it equal to the height of the footer… I’ve seen this behavior before… Testing… yeah, adding position:relative to html,body fixes that. No problems in other MODERN browsers, but it’s all screwy in IE7 (though 6 has no problem) and complete no-go in 5.x. Cute trick putting both margins on the top - NOT sure I’d trust it, but one margin instead of two is a neat idea.
Both of the latter two are giving me the same screwball layouts as your initial example… ONLY working in IE7.
– edit –
Oh, and on the last two, the comment placement is tripping the double render bug in IE… and on the last one part of the problem is the dynamic text inside the fixed height header is wrapping, increasing the height of the header content pushing the content down further than planned.
… and was playing with it - mein gott that was saggy around the midsection. The IE conditional comment when it’s USING * html hacks was a serious “whiskey tango foxtrot” as was the scripting assist… but it often seems people are afraid of expressions; that or never heard of them… all the display:inline triggers and mess of stuff on the LI was also kinda strange, since for inline-block there one can just set display:inline ONLY on the LI and then set the anchors to display:inline-block… Most unusual.
I rewrote it using my approach - and moving the content to BEFORE the sidebars. Interesting thing was that height:1% is that so long as it is on at least ONE element inside #pageWrapper it works… I was having trouble with it on #columnWrapper or it’s children since that was making content disappear in IE6 (but not 5.5?) - so I on a lark I put it on the menu - even on #mainMenu it fixes the Opera and IE oddities… which is pretty neat… and really weird.
I also noticed that the original seemed to have many problems come from the faux column technique - it didn’t expand past the browser height so when you scrolled down - hey where did my column backgrounds go? No shock, it shouldn’t; height:100% is based on screen height at that point, NOT the parent element. I’ve seen this issue a few times before and the best solution is actually to position them off bottom and not top, and then set the height on them to some completely absurd value like 99999em. Then it just gets chopped off at the top. The menu also was switched to using the negative margin overlap trick to scale them instead of the HTML formatting trick - I’d use the word-spacing/letter-spacing trick if FF 3.6 hadn’t completely screwed that one up.
Shaves about 3k off the total of that layout… Tested working in IE 5.5, 6, 7, & 8, Opera 9.62 and 10.2, FF 2 and 3.6, and the latest flavors of Saffy/Chrome… Though in 5.5 the side borders do not stretch to the full height; OH WELL - like we REALLY give a **** about IE5 at this point - I mostly just check for mobile users, mac ***'s and morbid curiosity at this point. For me IE5 and increasingly IE6 testing is “can they still USE the page” not “is it perfect”.
Ah, the joys of trying to find better ways of doing things… every time I see :before and/or :after with a bunch of empty generated content, I always think “there’s got to be a better way of doing this” - and I have yet to find a case where it’s not so; but then the same could be said for IE conditional comments, which to me are a giant warning flag saying “This developer didn’t know what they were doing”
Dunno what I did, but I broke my latest example - for some reason Opera started refusing to even GIVE you the ability to scroll… Seemed to be the faux-column technique at fault, so switched it to ‘top/bottom’ method and then sent the ‘off the top’ method to IE6/earlier…
Crazy stuff… Starting to remember why I use images for faux-columns.
Hi Jason,
It will take me a little while to catch up on your replies so I will start where I left off.
Those first two links were Paul’s examples and there should be nothing wrong with them in IE7. Most of us around here us “IE Tester” for IE6/7 and they are working fine for me there. Also there are links to browsercam screenshots in his barebones demo which confirm that all is well in IE7.
The difference between those first two links and the last two is the way the footer soak-up is handled. Paul used a top border on the first element in the wrapper to soak up the footer height, then pulled the wrapper itself through the top of the viewport with a negative margin.
My examples pull the footer up over the wrapper with a negative margin, then an inner div has a bottom padding (equal to the footer height) to keep the text from sliding under the footer.
Let me read through your other posts and I will reply back.
You mean the footer refresh issue? I never really sweated that one - figured if it REALLY mattered to users of the browsers that don’t render it right they could just refresh. It’s better than having the footer rendering in four different spots in four different browsers like yours did. Not sure I’d waste 15 lines of markup on fixing something that 0.0001% of users would ever come across. (especially since minimize/maximize/restore lacks that bug) - interesting to find out there’s a fix - but there’s got to be a way to clean that up somehow.
I thought the same when I first saw the threads (Eric Waton’s I think) discussing this. Paul said something about “it should work for everyone” and maybe I’m wrong in the assumption that people who see a working page go screwy will refresh— to me, hitting refresh when something dies is the equivalent of the kick you give to the [appliance] when it starts making weird noises or something— something automatic done without thought. A reflex. The again, I assume people use the Back Button and I’ve just met a few who never do.
I used an Opera hack once for a 100% height page because it was a single line of HTML code and that didn’t bother me too much… but haven’t used it since.
When I’m back at work I want to look at all those sites in IE7. I have a real live one, not the IETester, and I can set the large fonts too.
That’s when I use clearfix instead of overflow as well… however, you really don’t need all that code you see coming with the clearfix.
You can make it work just fine for 99.99999% of the cases and users by
-triggering haslayout out in the open for IE
-then about 4 lines of code #element:after {
content: " ";
display: block;
clear: both;
height: 0; /you’d think this one was for IE, but actually, I need it for FF/
}
If I remember right I added the IE6 CC later and never moved that one * html hack for the #nav li to the CC, no biggy.
Well it’s not that we are afraid of expressions nor that we have not heard about them. In fact it is an expression being used, the scripting assist just keeps the expression from running constantly and becoming a resource hog.
all the display:inline triggers and mess of stuff on the LI was also kinda strange, since for inline-block there one can just set display:inline ONLY on the LI and then set the anchors to display:inline-block… Most unusual.
Yes I see what you are saying and that does seem cleaner after looking at your recoded version. At the time I coded that IE6/7 needed haslayout on the anchor and inline-block did the trick and did not seem cause any problems with good browsers.
Now, back to the sticky footer and as to why you are seeing things different on your end is what I am trying to track down.
I have set up two bare bone examples without any IE8 or Opera fixes so don’t even try them there as they won’t work. I also want to see if the lack of the :before and :after blocks changes the way FF renders things for you. I mentioned that Paul’s version uses a top border on the first element and I used an inner div with bottom padding.
Both of the latter two are giving me the same screwball layouts as your initial example… ONLY working in IE7.
And those later two were the ones that pulled the footer up with a negative top margin.
So, tell me how these work for you in FF, they should both work for you in IE6/7 also. (Again, not for IE8 or Opera just yet. These are bare bone examples)
SECOND one seems ok, first one the footer is too high by… looks like about one line-height.
It almost looks like when #wrapper moves up, it’s taking footer with it a wee bit extra.
– edit – and when I resize the window with that first one’s tab selected, firefox crashes. BIG SHOCK (not) - hard to say if it’s that page, or that I’ve never seen a stable version of firefox on any OS platform. Hell, I could lock up the entire 1.x and 2.x branches in 15 minutes use at about 256 megs RAM used and 100% cpu for 20 minutes plus until you had to kill it… 3.6 actually just ‘shuts down’ - as Hunter would describe a mac ‘shutting down’… You didn’t save, you didn’t close - it’s gone, it’s “shut down”… unless you actually want to shut down a mac…
there’s a reason I use Opera as my primary browser, at least when it crashes it auto-saves my open tabs.
I think that is exactly what the problem is on your end seeing how you mentioned you keep your browser font-size set very large.
You set your font-size on the body to 85% when you write code, is that why you keep a large font-size set on your browser? Why would you want to try to control the viewers base font-size? I’ll admit I’m not a font expert but I have read and seen enough to know that it is not good to try to tell the viewer how they need to view your page.
It has always been my opinion that the base font-size should be set at 100% or none at all. Not to go off on a big rant about it but I would be curious to hear a brief explanation of your reasoning behind it.
In those last two links I posted (the ones you just reviewed) I have reworked them a little bit and took all vertical margins and paddings off of the footer “p”. Then I set overflow:hidden; on the footer since I am guessing it was the line-height that was spilling out on your end. I set some BG colors on the “p” tags as well so I could see what was going on.
Review those last two links again in your browser and see if the bottom gap is gone from the footer for you now.
I am able to “zoom text only” in FF and Safari until I can zoom no more without the footer overflow hiding the text. I keep my default browser font-size set at 16 though so the same may not be true for you. Regardless, the worst that should happen would be that the bottom portion of the footer text would begin to get cut off. The footer itself should not have any gap under it though.
…and when I resize the window with that first one’s tab selected, firefox crashes. BIG SHOCK (not) - hard to say if it’s that page, or that I’ve never seen a stable version of firefox on any OS platform.
there’s a reason I use Opera as my primary browser, at least when it crashes it auto-saves my open tabs.
I highly doubt it is the page crashing your FF, it is valid code. FYI, I am a FF user and like you I have my reasons too. I can’t even remember the last time FF crashed on me, and when it did it was because of some invalid code on the site I was at.
It has always been my opinion that the base font-size should be set at 100% or none at all. Not to go off on a big rant about it but I would be curious to hear a brief explanation of your reasoning behind it.
In one of the many long-winded font-size threads, Dan Schulz gave a long description of why he set things at 85%. I also use 100% because I worry less about people being unhappy with letters too large than about those who think it’s too small.
I can’t even remember the last time FF crashed on me, and when it did it was because of some invalid code on the site I was at.
Mine will suddenly just vanish… you see a brief second of what looks like the window minimising, then poof. But I always figured it was a Linux thing. Trying to start another copy tells me “Firefox is already running, please close the current one before starting another”. By the time I get into the terminal to find the ID to kill it, it’s finally gone and I can restart, where it forgets all the tabs that were open (so I guess it’s not a “crash”). No particular sites seem to set it off, and it doesn’t happen often enough to stop me.
Add to that the :before for what position:relative on html,body would fix, the lack of a line-height or fallback family on the font declaration (NEVER trust default line height) that ‘demo’ is filled with issues.
I’m bedridden on the netbook at the moment, so the code might be a bit sloppy / well below my normal level of quality. (why I ended up coming back to sitepoint - needed something fresh since DP is too mercenary, and everything else is spam hell or nube city - I missed people who at least have SOME clue what they are doing). Moved the H1 into