James Wilson

Web developer. Drupal enthusiast. Surfer and musician. I craft bespoke websites at Bluespark.

2014 Sticky Footer Solutions

We’re working on a Drupal distribution of sorts that offers a number of different themes included, and I needed to do some research into to the cleanest solution for including a generic, reusable and inheritable Sticky Footer to be packaged in a base theme, and easily turned on or off in sub-themes as necessary.

Searching Google always turns up a number of solutions, so I thought I would condense the options down into a list of 4 basic options, and list the pros and cons of each.

1. The Classic CSS Sticky Footer (html5 version here):


  • CSS/HTML only.
  • No javascript or extra HTTP requests needed.


  • Requires the footer height be known, and set to a fixed value in CSS.
  • Requires non-semantic HTML code structure changes.
  • Doesn't work well when using dynamic content such as from a CMS.
  • Doesn't work well for responsive designs, where height may change dynamically based on contents and width of screen.

2. A Responsive Sticky Footer CSS solution using display:table-row


  • Don't need to know the height of the footer.
  • Is a responsive solution.


  • Could be considered a hack, due to CSS use of .
  • Can cause layout/display issues or break the site design of some sites, requiring more time and attention to fix.

3. The CSS Flexbox solution.


  • Zero HTML code changes required.
  • Very little CSS code (5 or 6 lines).
  • Snappy response time and no display issues (requires no JS event listeners or processing).
  • Could be the best choice as a progressive enhancement if stakeholders are willing to accept limited browser support.


  • Flexbox still has rather poor browser support,, many current browsers still require vendor prefixes.
  • Would require a fallback solution for supporting IE9 and below.

4. A Javascript-based responsive solution.


  • Encapsulated solution - contained in a single javascript file, may be placed in the base Casa theme, and then automatically inherited (or specifically disabled) by any sub-theme.


  • Performance - extra HTTP requests.
  • Maintainability - Adds more jQuery/javascript bloat.
  • Hacky - Requires extra code to listen for screen resize, and to restrict itself from overloading the browser.

Here is the above information condensed into a table format:

Solution Responsive Browser Support Pure CSS Clean (No hacks)
No Yes Yes
No; some non-semantic html is required.
Yes Maybe; some consider using display:tables-row is not good use of CSS.
Yes No Yes Yes
Yes Yes No Maybe; requires extra code to listen for screen resize and to restrict itself from overloading the browser.