Sticky footer with two background images

I can’t get this sticky footer to work.

The problem arose when I wanted to add two background images (one in ‘body’ and another in a div, #bg-image that surrounds the main container.

It works if I remove the div#bg-image but I want to keep this top gradient. Is there any way to fix this or is there an alternate approach?

http://errors.simplrweb.com/error.html

Thanks.

Sorry, but what is your question? I’m confused about what you’re having trouble with. Are you trying to make it so the footer isn’t separated by all that blank space? So it is attached to the body content container?

By the way, did you do this on purpose?:


#footer {
	background: url(images/footer_bg.png) repeat-x;
	[B]h/eight: 110px;[/B]

That’s because you declare a min-height: 100% on both the #container and #bg-image. That is never gonna work. The 100% will only apply to the bg-image in this case

@svcghost: I removed that CSS line. I want to have a gradient in the background but also want the container that hold the main website (without the footer) to extend to the bottom of the viewport.

Here is the site without the gradient:

http://errors.simplrweb.com/withoutgradient.html

That works because, like I said in post #3. The min-height: 100% now applies to the container only which now extends to the desired 100% :wink:

What if you put the bg-color div ID AFTER the container? so it starts and ends inside of the container div ID

I put one bg image on the html tag but I am not sure it this will work on all browsers.

http://errors.simplrweb.com/sol1.html

Hi,

Unfortunately, you are using a sticky footer routine that even if you had implemented it properly would fail in IE7, IE8 and all versions of opera.

At present it is actually broken in all browsers as you have effectively made a footer that will never be visible on any page until you scroll to see it.:slight_smile: The footer in your example is always below the fold and never in the initial viewport even when there is no content. A sticky footer should sit on the bottom of the viewport (not under it) when there is little content and on longer pages sits at the bottom of the document.

The Sticky footer FAQ explains the only way to make a proper sticky footer that works in all browsers and is the one I suggest using (even if I say so myself :)).

Regarding placing the image on the html element then it should work good enough for your example but usually applying a background image to html can be awkward in 100% height situations. What will happen is that the body background image will stop dead at 100% height and then the background on the html element will show through. As I said that probably won’t be an issue in your layout as your fade stops short anyway and will only look odd at very small screen heights.

Paul is right as to the current method being broken – but it gets worse the deeper one looks. You’ve got dozens of ‘elements for nothing’ like all those extra div in the footer, the clearing div, etc… Your comment placement after the tags is tripping the disappearing content bug in legacy IE, and of course since you have a closing tag right there do you REALLY need to say “end”?.. Clearing DIV like it’s still 2001, an H2 for what should be a SMALL tag inside the H1 (are you starting a new section? No? Then why is that a H2?!?), the unnecessary wrapper around the menu, no images off graceful degradation (defeating the POINT of using a image replacement method), etc, etc… even little things like that malfing “target” attribute that doesn’t even exist in the doctype you are working with. (and shouldn’t be used for that in the first place!)

As to doing two body backgrounds, one for the “repeat-x gradient” and the other for the “repeat tile” I’d suggest just putting a empty div before the 100% height wrapper with a negative bottom margin on it equal to it’s height. This would give you the extra element, avoid having to play with z-index, etc, etc…

My approach the markup would end up looking something like this:


<!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=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<title>
	Project 137 - p1
</title>
    
</head><body>

<div id="gradientTop"></div>

<div id="pageWrapper">

	<h1>
		ABC Masonry<br />
		<small>Beautiful Slogan Goes Here</small>
		<span></span>
	</h1>
		
	<ul id="mainMenu">
		<li><a href="index.html">Home</a></li>
		<li><a href="index.html">About Us</a></li>
		<li><a href="index.html" class="current">Services</a></li>
		<li><a href="index.html">Blog</a></li>
		<li><a href="index.html">Employment</a></li>
		<li><a href="index.html">Locations</a></li>
		<li><a href="index.html">Contact Us</a></li>
	</ul>
	
	<div id="columnWrapper">
	
		<div id="content">
			<p>
				"Art not thou the leg-maker? Look, did not this stump come from thy shop?"
			</p><p>
				"I believe it did, sir; does the ferrule stand, sir?"
			</p><p>
				"Well enough. But art thou not also the undertaker?"
			</p><p>
				"Aye, sir; I patched up this thing here as a coffin for Queequeg; but they've set me now to turning it into something else."
			</p>
		<!-- #content--></div>

		<div id="sideBar">
			<p>
				"Art not thou the leg-maker? Look, did not this stump come from thy shop?"
			</p><p>
				"I believe it did, sir; does the ferrule stand, sir?"
			</p><p>
				"Well enough. But art thou not also the undertaker?"
			</p><p>
				"Aye, sir; I patched up this thing here as a coffin for Queequeg; but they've set me now to turning it into something else."
			</p>
		<!-- #sideBar --></div>
		
	<!-- #columnWrapper --></div>
	
<!-- #heightWrapper --></div>	
	
<div id="footerWrapper"><div id="footer">
	<ul>
		<li><a href="index.html">Home</a></li>
		<li><a href="about.html">About Us</a></li>
		<li><a href="blog.html">Blog</a></li>
		<li><a href="services.html">Services</a></li>
		<li><a href="portfolio.html">Portfolio</a></li>
		<li><a href="usefullinks.html">Useful Links</a></li>
		<li class="last"><a href="contact.html">Contact Us</a></li>
	</ul>
	<div>
		&copy; Your Copyright Info Here. Designed by:
		<a href="http://www.simplrweb.com">SimplrWeb</a>
	</div>
	<ul id="siteInfo">
		<li><a href="http://jigsaw.w3.org/css-validator/check/referer">CSS</a></li>
		<li><a href="http://validator.w3.org/check?uri=referer">XHTML</a></li>
		<li><a href="sitemap.html">Sitemap</a></li>
		<li><a href="blog.html">RSS Feed</a></li>
	</ul>
<!-- #footer, #footerWrapper --></div></div>

</body></html>	

I have time later I’ll toss together the CSS to show you how I’d approach that – which ends up very similar to the height technique Paul linked to. (though I have my own IE8 fix that works just as good).

… and here’s how I’d approach that same layout:

http://www.cutcodedown.com/for_others/drakke/template.html

As with all my examples the directory:

http://www.cutcodedown.com/for_others/drakke

is unlocked for easy access to the CSS and images.

A few minor markup changes but nothing major – In writing it I figured out (I think) what you wanted for a ‘double background’ on the footer, so I got that working.

I redid all of the image so it no longer relies upon alpha transparency to function – as I’ve said many times on these forums I’ve rarely seen a layout that ‘required’ the use of them, and frankly if it does, I don’t consider it a viable layout. I had to pull some tricks thanks to the overlapping body gradient (see #pageWrapperGradient and it’s nested DIV) but in the process cut the images down to 14k. The biggest savings came from taking that large logo .png and breaking it into a .png and a separate .jpg… and saving all those gradients as greyscale didn’t hurt either. Ends up with one more handshake for one extra file, but that’s worth the 200ms extra overhead to get rid of 41k of filesize.

A big change is the menu background – I make menu states a single image with rare exceptions.

Of course, single image menu and the fixed height footer means that BOTH have to use px metric fonts or you risk the layout breaking for large font/120dpi users (even though FF’s retard ‘text only’ zoom will mess that up anyways – but I usually tell the folks who select that style where the cliff is…)

That remains one of the biggest pains is that content should always be %/EM, but you use it on anything that is interacting with a image, particularly fixed heights it’s gonna be broken for anyone who isn’t on that perfect mix of 96dpi/no zoom. You generally have to figure out WHICH zoom you’re gonna support. Thankfully 14px is big enough that even large font/120dpi users (like myself) won’t ***** about them – unlike the absurdly undersized and illegible fonts you had in your original footer.

I ended up using zoom:1 a lot – but like most CSS things that don’t validate so long as you know WHY it’s there, you can ignore it. (Unlike HTML validation where there’s no legitimate excuse, CSS is… well…) – I had to use zoom since one of my rules is NEVER declare width or height the same time as padding or border… which is why the page works even in IE 5.5

Tested working IE 5.5, 6, 7, 8 and 9 Beta, FF 3.5.whatever and 3.6.whatever (stupid thing updates so often I can’t even keep up with the version numbers), and the latest flavors each of Opera, Chrome and Safari. Valid XHTML 1.0 Strict, would be valid CSS 2.1 if not for the IE specific zoom property.

… and your original was 11k of HTML+CSS, this rewrite is 7k… so from 66k in 11 files to 21k in 12 files while working just about everyplace that actually matters. It MAY be possible to further reduce the number of separate images, but I’m not sure it’s worth the effort.

– edit –

oh, and all the .png have been GAMA stripped so IE won’t screw up color matching. Important since I changed the 5x5 background tile to a .gif

I think Jason (deathshadow) covered just about everything there :slight_smile:

@deathshadow60 - Thanks for the code. I think I have most of it now. Really helped a lot. I have much to learn. :slight_smile:

http://errors.simplrweb.com/mod1.html

PS. I should have refreshed the thread before posting. I will look at this carefully. Thanks again.

@deathshadow60 - This is really great! There is so much here to figure out.

Does this mean that you don’t need to use a IE6 alpha transparency fix?

No you don’t need a png fix as Jason redid the images without the need for transparency as he overlaid a faded image instead. There isn’t a transparent image on top of the background anymore it is just a normal image with the fade already in place and no transparency.

Does this mean that you don’t need to use a IE6 alpha transparency fix?

This is great in several ways:
-an image with actual alpha transparency has (generally) a bigger filesize than one who doesn’t. So you have smaller images.
-IE6 doesn’t need a fix
-the PNG fix for IE6 is also large, so you’ve reduced total filesize (of the page) even more
-the PNG fix for IE6 introduces some bugs in some applications (if you use the semi-trans image on something you want to also be clickable like a link is one example), so you’re avoiding them as well
-the PNG fix for IE6 would still not have worked for anyone stuck with IE6 who knows it’s not a secure browser and have scripts off… or their employer (banks especially still have IE6) block scripts with a firewall or something.

Correct.

As a rule I either avoid designs that require that outright — or find ways to do the same thing without it.

In this case it was fairly simple to avoid because it’s a fixed width layout – though as a rule I also avoid doing that as well. The method I used was to first render the page without content, screencap, then slice up the appropriate bits. By aligning the background to ‘top center’ you can be reasonably sure the composited version of the image will line up across all systems, again thanks to the fixed width…

I’ll give you a quick rundown of what/why I did what I did. When I wrote it I tried to add some comments for the more unusual bits and pieces.

So first we needed a repeat-y tile for the bottom half of the shadow-edges:

Then we need the gradient versions of that shadow to apply over them:

That image might seem a little confusing because it’s reversed – the right side gradient is on the left and vice versa… I did it this way because if you look in the code we have a double nested DIV as our hook for those:

<div id=“pageWrapperGradient”><div></div></div>

The outer div has a fixed height and float wrapping behavior. This allows us to float the inner div… by having the “left gradient on the right of our image” we can place it in the CSS thus:

background:url(images/pageWrapperGradient.png) -20px 0 repeat-y;

Sliding it right 20px means only the left half shows – with nothing to the left of the image it doesn’t overwrite the white background of the outer pagewrapper.png – so we don’t need to draw the middle of the image saving us a lot of bytes in the file size.

The inner DIV gets that same 20px width, the same 540px height and floated right… Then we just use that same image file and don’t slide it at all. The 20px width chops off the “left hand gradient” that’s on the right. It’s a sneaky trick, but one that can really save you on bandwidth and time.

The final piece of the puzzle is the negative bottom margin on these elements – you’ll see that both #pageWrapperGradient and #topGradient get bottom-margin:-540px; – negative margins are a very powerful technique once you get a hang of them. The best way to explain it is the same way I explain how position:relative and visibility:hidden work – to think of it in your mind as there being two separate ‘boxes’ an element has – the “render box” – which is what’s drawn on the page, and the “flow box” which is what’s used to compute how it fits into the page and how other elements fit around it.

Negative margins basically “shrink” the flow box – by making a negative bottom margin equal to an elements height, you basically make it ‘zero height’ in flow, while it still renders the same size as normal.

It’s why I compare it to position:relative. One of the magical things about position:relative is that if you move the element with top/left/right/bottom the ‘flow box’ as I call it remains in place at it’s original size, while only the ‘render box’ is moved. Visibility:hidden removes the render box entirely, but leaves the flow box in place.

The ‘two box’ model is not how it actually works, but it’s a very good way to explain it… <mcHawking>It oversimplifies and it ain’t quite right, but for purposes here it will have to do, 'cause I ain’t got the time to explain it to you.</mcHawking>

The negative margin trick is also how the sticky footer works. #pageWrapper is set to min-height:100%; with the footer after it. By putting a negative top margin on the footer we can make it ‘ride up’ over #pageWrapper. We then just pad the bottom of Content to make room for the footer so it doesn’t overlap the content. For things like this it tends to be much more reliable than position:absolute or position:fixed. The latter of those I try to avoid at all costs because ‘fixed’ just cannot be relied upon cross browser – and if that means taking an axe to a design idea, then I take the axe to the artsy fartsy design idea. After all, people visit websites for the content, not the goofy graphics we hang around the content!

A lot of HTML purists will piss and moan about the inclusion of those div to do – but the alternatives include larger alpha transparency .png files, use of CSS3 properties that aren’t ready for real world use, relying on a fat javascript to fix it, or more smaller separate files increasing the number of handshakes. In that way HTML, CSS and Images pretty much are a balancing act… If I can use four lines of CSS to reduce something in the markup to one line I’ll do it because CSS is cached across pages – conversely if four to eight extra lines of HTML means it works all the way back to IE 5.5 with zero extra coding effort while at the same time reducing two or three 16k files to a single 4k file, I’m on that like a hooker on a five dollar bill.

Besides, elements like DIV and SPAN’s “semantic meaning” is that they add no semantic meaning to their content or the page – that’s what they are for. You’ll often see me complain about people using too many DIV, but that’s your typical “DIV for nothing” like slapping a DIV around a main menu UL or a DIV ID=“heading” around the h1 and UL – which is just a waste of code. Again, right tool for the right job attitude. (and part of why I consider HTML5 a bunch of pointless bloat and is little more than a new HTML 3.2)

You may also notice a few smaller details in there. CSS side for example I intentionally avoid EVER declaring width and padding at the same time. If I want padding on a width, I margin or pad the child elements. This not only helps with making sure that you don’t have IE box model headaches in 5.x, it also seems to just make cross browser code easier to do and means less math. It’s usually easier to say “width” on one element and margin on it’s companion – like I did with the columns, than it is to calculate the width of each one… It’s often easier to put a width on a outer element and pad in the child than it is to calculate the width of a child.

In that way you can see I also avoid declaring heights as much as possible. The #footerwrapper is a great example of this… I do have to add it up to come up with the amount for that negative margin, but if you know what your line-heights are and add up all your padding, and know how many lines it is total, there you go. In this case the 10px top/bottom margin on #footerWrapper plus 5px top/bottom padding on #footer + 5px top/bottom padding on three lines of UL/DIV + three lines of 16px line-height ends up:

20+10+30+48 ==108px

I do the same thing on the mainMenu – I made the image 32px tall (you had 29 I think?)… 16px line height plus 8px top/bottom padding gives us 32px, so we don’t need to SAY 32px anywhere.

I also put the two menu states into a single file, then just slide the background around on hover. This avoids the ‘delayed load’ caching issue that can make for an annoying delay on first hover, reduces the number of files making the page load quicker, etc, etc…

Also, notice my commenting style:

<!-- #sideBar –></div>

This is NOT some arbitrary technique – comments between sibling elements can often lead to rendering bugs in different browsers – the most famous of which are IE’s “disappearing content” and “double render” bug that can occur if you put comments between floats, but I’ve also discovered that in Gecko it can accidentally be treated as a block level element in some cases, and Safari on the iPhone will sometimes randomly show the text in a comment during scrolling… (It flashes very quickly). Placing the ‘closing’ comment before the tag completely removes the possibility of any of those bugs showing up. Don’t know why, but it works.

When you are closing multiple elements on the same line – good for when you have ‘wrappers’ that should have nothing else inside them, I condense the comments for the same reason.

<!-- #footer, #footerWrapper –></div></div>

putting them of course in the order I’m closing them.

You’ll also notice I don’t waste time saying “end” – of course it’s the ‘end’, that’s what </div> means! I also use the CSS type selectors (# and .) to say if it’s a class or ID. Code consistency makes it pretty clear what’s going on.

Commenting is something you see people screw up all the time, and a LOT of the hacks people throw at IE would be unnecessary if you either fixed the comments like I do above, or strip them out entirely. Commenting is a good thing, but thanks to the browsers being #DDD (Carlos Mencia Gray) you have to be careful how you do it. There’s also good commenting and bad commenting – and there’s a LOT of bad commenting out there. If you use verbose names that say what things ARE, and semantic markup which also says what things ARE, comments can often become pointless – “start” comments topping the list on that.

Something I always point people at is an article on IBM’s Linux developer website:

http://www.ibm.com/developerworks/linux/library/l-clear-code/

It’s meant for C programmers, but anyone writing code can come away from that article with some really good lessons on writing code in a better way.

I think that covers some of the odder points – I imagine as you go through it you’ll probably have some more questions though.

For IE6 pngs.

This thing has been discussed extensively on these forums, but I feel the need to chip in with what my view:

I just “make” (as in “save as” w/ other options) another set of graphics for it, for IE6. I see IE6 as a bad reason not to use png transparency the right way. Or to use filters or js fixes.

The way it is: make modern, normal graphics (optimized, mind you) for use in modern UAs. IE6 will not be the common denominator for my web page, it will be an exception, treated as such.

Is there a better way to add graphic buttons (with links) to the header?

I have added this to the XHTML after the header h1 tag:

<div id=“contactButton”>
<a href=“#” class=“contact”>Contact</a>
</div>

And this is the CSS:

#contactButton a.contact{
position: absolute;
background: url(images/contact.jpg) no-repeat;
width: 176px;
height: 56px;
right: 23px;
top: 53px;
text-indent: -9999em;
}

#contactButton a.contact:hover {
background: url(images/contact.jpg) no-repeat;
background-position: 0 -56px;
}

I want to add several buttons. Is it possible to use <span> tags within the h1 tag rather than absolutely position a button over the header h1?

Thanks.

I don’t understannd you, what are you going for? Several buttons? Of images? Links? Have no clue really what you’re asking.