Our objective is simple: Make the footer of our web page stay at the bottom even if the page’s content area is shorter than the user’s browser window.

This, by far, is one of my *favorite* things to do. It makes the web layout so much more appealing and creates a very professional feel. I ended up kicking myself the very first time I tried to add this functionality to a project early in my career (ten years ago … already!?) when I found out just how easy it was. I take solace in knowing that I’m not alone, though … A quick search for “footer stick bottom” still yields quite a few results from fellow developers who are wrestling with the same frustrating experience I did. If you’re in that boat, fear no more! We’re going to your footers in shape in a snap.

Here’s a diagram of the problem:

Unfortunately, a lot of people try to handle it with setting a fixed height to the content which would push the footer down. This may work when YOU view it, but there are several different browser window heights, resolutions and variables that make this an *extremely* unreliable solution (notice the emphasis on the word “extremely” … this basically means “don’t do it”).

We need a dynamic solution that is able to adapt on the fly to the height of a user’s browser window regardless if the resize it, have Firebug open, use a unique resolution or just have a really, really weird browser!

Let’s take a look at what the end results should look like:

To make this happen, let’s get our HTML structure in place first:

<div id="page">
 
      <div id="header"> </div>
 
      <div id="main"> </div>
 
      <div id="footer"> </div>
 
</div>

It’s pretty simple so far … Just a skeleton of a web page. The page div contains ALL elements and is immediately below the tags in the page code hierarchy. The header div is going to be our top content, the main div will include all of our content, and the footer div is all of our copyrights and footer links.

Let’s start by coding the CSS for the full page:

Html, body {
      Padding: 0;
      Margin: 0;
      Height: 100%;
}

Adding a 100% height allows us to set the height of the main div later. The height of a div can only be as tall as the parent element encasing it. Now let’s see how the rest of our ids are styled:

#page {
      Min-height: 100%;
      position:relative;
}
 
#main {
      Padding-bottom: 75px;   /* This value is the height of your footer */
}
 
#footer {
      Position: absolute;
      Width: 100%;
      Bottom: 0;
      Height: 75px;  /* This value is the height of your footer */
}

These rules position the footer “absolutely” at the bottom of the page, and because we set #page to min-height: 100%, it ensures that #main is exactly the height of the browser’s viewing space. One of the best things about this little trick is that it’s compliant with all major current browsers — including Firefox, Chrome, Safari *AND* Internet Explorer (after a little tweak). For Internet Explorer to not throw a fit, we need concede that IE doesn’t recognize min-height as a valid property, so we have to add Height: 100%; to #page:

#page {
      Min-height: 100%;  /* for all other browsers */
      height: 100%;  /* for IE */
      position:relative;
}

If the user does not have a modern, popular browser, it’s still okay! Though their old browser won’t detect the magic we’ve done here, it’ll fail gracefully, and the footer will be positioned directly under the content, as it would have been without our little CSS trick.

I can’t finish this blog without mentioning my FAVORITE perk of this trick: Should you not have a specially designed mobile version of your site, this trick even works on smart phones!

-Cassandra

It’s easy to get lost in a sea of numbers when you start talking about IPv4 and IPv6 address space. With the exhaustion of IPv4 address space and the big push toward IPv6, everyone’s talking about address blocks, usage justification and dual stack compatibility, but all of those conversations presuppose a certain understanding of why IP addresses are the way they are. Someone can say, “The IPv6 pool is exponentially larger than the IPv4 pool,” but that statement needs a little context when you hear that providers like SoftLayer are provisioning a free /64 IPv6 allocation of 18,446,744,073,709,551,616 addresses to a single server. If the entire IPv4 pool on the Internet is 4,294,967,296 addresses and we’re giving away that many IPv6 addresses to a single server, a simple question logically follows:

Are the Internet authorities being irresponsible when they’re allowing such huge numbers of IPv6 addresses to be assigned to individual servers without a demonstrated need for that many addresses? Will this “wastefulness” lead to another IP address pool depletion in our lifetime? These questions are completely legitimate, and they’re much easier to explain in a visualized format than they are if we answered them line-by-line in text:

The video duration might seem intimidating, especially if you consider that all 15 minutes are spent talking about IP addresses (Woohoo!), but there’s a lot of information, and we did our best to break it down to simple pieces that logically follow each other to help you get the full picture of the world of IP addresses. We explain what CIDR Slash (/) Notation (where you see IP address blocks written as “192.0.2.0/24″), and we offer a simple trick to calculate the number of distinct addresses available in a given IPv4 block. There’s a fair amount of witty (and not-witty) banter and at least one use of the word “ridonkulous,” so if you enjoyed the DC Construction video commentary, you’ll get a kick out of this one too.

Toward the end of the video, we speak directly to why SoftLayer is able to give a /64 of IPv6 addresses to every server and what that means for the future of the IPv6 space.

Fun Fact: SoftLayer IP Address Space*

• IPv4: 872,448 Addresses
• IPv6 (/32): 79,228,162,514,264,337,593,543,950,336 Addresses

*Does not include IP space assigned to The Planet

Did the video help you wrap your mind around the differences between IPv4 and IPv6? Do you have any more questions about the differences between the two or how SoftLayer is approaching them?

-@khazard