Wednesday, 8 February 2017

Foolproof Front-End Asset Cachebusting

Here’s a scenario you’re probably familiar with if you’ve done any amount front-end development. After deploying a CSS or JavaScript change and notifying the client, you hear back that they’re not seeing the updates. This is usually because their browser has the old CSS/JS cached and needs to be hard reloaded to re-download the new assets.

This isn’t too big of a deal for low-traffic sites or small changes, but what about when you’re deploying a significant change to a high-traffic site? I had a scenario recently where I was deploying a new header and navigation to a high-traffic website that had been using the old header styles for years. We’d rebuilt it from the ground up — new HTML, CSS, JS, everything — so without the new front end assets, the page looked completely broken.

Version Parameter

A common trick to force the browser to re-download assets is to add a version parameter to the query string of the CSS or JavaScript file you’re linking to:

Every time you make an update to the file, you’d update the version to a new value, which the browser reads as a new URL it must re-download to it’s cache. This is a pretty good solution, except that you have to remember to change the version every time you’re deploying updates that necessitate the browser re-download new assets.

Timestamp Versioning

One solution I’ve seen to this is using a timestamp as the asset version. This is especially helpful during development because it ensures you have the freshest version of the file on every page load:

While the timestamp method works well for development, but you wouldn’t want to use it in production since it forces the browser to re-download the assets on every page load — no bueno. Ideally we’d like a solution that only forces the browser to updates its cache when something changes, but makes use of the cache for performance reasons when it can.

File Modified Versioning

The solution is to set the version parameter to the timestamp of the last file modification for the asset you’re linking to:

Think about it — this solves all of our problems. Without any manual work, we’re guaranteed the browser will re-download our assets every time they change. And if they haven’t, the URL remains the same on as the last page load and the browser can keep its existing cache. Viola!

Integrating in WordPress

Since most of my work takes place in a WordPress environment, here’s how you’d integrate this using WordPress’s wp_enqueue_style() and wp_enqueue_script() functions:

Whatever you pass to the 4th parameter in both enqueue functions serves as the value for the ver parameter in the URLs to the asset files generated by WordPress.

Other Options

As is usually the case, CSS-Tricks has a great post listing a bunch of different methods to tackle this problem.

If you have a favorite solution, let me know in the comments.

Tuesday, 24 June 2014

Responsive, Flexible-Height Sticky Footers with JavaScript

Back in March, I wrote a post about creating sticky footers with CSS using display: table and display: table-row. Since I wrote that post, it’s become by far the highest-traffic post on the site. Obviously it’s filling a need.

Since writing it though, I’ve discovered some issues with that approach. Sliders seem to be the biggest problem. For whatever reason, responsive sliders like bxSlider, RoyalSlider, and a few others break when they’re placed inside of a table or an element with display: table applied. Since the sticky footer method I posted applies display: table to the <body>, that pretty much means that responsive sliders break everywhere for me.

In April, Cory Simmons posted about using JavaScript for Responsive Dynamic-Height Sticky Footers. I mentioned in my post that I didn’t really care for the idea of using JavaScript to power sticky footers, but I must admit that I like the approach he came up with:

See the Pen Responsive Dynamic Height Sticky Footer by Cory Simmons (@corysimmons) on CodePen.0

I think it really depends on what you need. If you’re building out a lightweight site that’s unlikely to use sliders or other more complex JavaScript components (I can only guess that display: table could prove problematic for them as well), then the CSS solution might be fine. For bigger sites though with more complex content, you might be best to go the JavaScript route.

Tuesday, 25 March 2014

Responsive, Flexible-Height Sticky Footers in CSS

Since I’ve been in the game, front-end devs have been wrestling with sticky footers like it was going out of style. I’m no exception, but today I learned a trick that made things a lot easier.

Before we go on though, I’d like to explain the problem briefly. It’s common for websites to have a header, a content section and a footer. On pages with a lot of content, the content takes up enough vertical space to push the footer to the bottom of the browser window. But, on pages with little content, sometimes the content does not take up enough vertical space to push the footer to the bottom of the window. This leaves the footer sitting oddly in the middle of the screen.


There are several solutions, each with their own pros and cons.

The Old Way

The old way works well, except that it relies on the footer to be a fixed height at all times. In responsive sites, this is rarely the case. Of course, you could write JavaScript that detects the footer height and adjusts the CSS accordingly, but that’s neither clean nor performant. A CSS-only solution would be better.

The display: table Trick

My new favorite approach to the problem looks something like this:

The only real caveat to this solution that I’ve encountered so far is the styling limitations present with elements using display: table-row. Often padding, margin, etc. don’t behave as expected. This is easy enough to work around by adding a <div> or something inside the .page-row and styling that:

Why not Flexbox?

As I understand it, Flexbox handles sticky footers very well. If you’re in a position to be able to use Flexbox without worrying about browser support, go for it!

Tuesday, 20 November 2012

Code Smells in CSS

Harry Roberts wrote a great article on CSS Wizardy about things he looks for in CSS that give him an idea about “its quality, its maintainability and its integrity…”

A few of my favorites:

Rulesets should only ever inherit and add to previous ones, never undo.

Basically, if at any point you’re removing previously-declared styles from an element, you’ve probably applied the styles too early. I’m sure I’ve been guilty of this one.

[IDs] are of no use to anyone and should never be used in CSS.

Only recently have I begun to agree with this vein of thought. There’s no harm in replacing #header with .page-header, but there are situations where it would be beneficial — especially on larger sites. This certainly doesn’t hurt his argument either.

Wednesday, 11 July 2012

Resources for Retina

Prompted by the recent rise in retina devices such as the iPad 3 and Retina MacBook Pro, I’ve been exploring ways to make my websites more retina-friendly. Basically, I’ve found a couple of major options:

  1. Use vector assets such as icon fonts or SVG graphics.
  2. Detect for retina and use @2x images.

Here are a few few of blog articles, tools and resources that I’ve been relying on.

Icon fonts

I’ve been using icon fonts a lot recently. Basically, instead of using image files for your icons, you create a font file out of vector icons. Benefits include being able to infinitely scale, style and animate via CSS.

  • Pictos Server: This can best be described as Typekit for icon fonts. You select the icons you want, associate them with a character, and then the system builds you a hosted, built-to-order icon font based on the Pictos icon set.
  • Symbolset: Symbolset is the first semantic symbol fonts I’ve seen. Simply put, as you type certain, pre-defined keywords, the keyword is automatically replaced by an icon in browsers that support Open Type features. For example, you might type the word “world” and instead of the text “word,” a globe icon appears in its place. Clever, huh? I expect to see a lot more semantic sets like this soon.
  • Fontello: This is much like Pictos Server, except that instead of being limited to the Pictos iconsets, you have access to a number of open-source icon fonts. Also, you must host them yourself.
  • Chris Coyier wrote a good post about the HTML for icon font usage as well as handy roundup of icons fonts currently available.


SVG graphics are another useful tool that I’ve only recently begun taking advantage of. For some reason, I had been under the wrong impression they were going to be terribly difficult to implement and thus had been steering clear of them. Actually, they couldn’t be easier.

  • This blog post on the IEBlog (yes, I just did that) seems to be a good place to get acquainted with SVGs and understand their use cases.
  • SVG Export Fireworks Command: If you’ve spent any time looking for Fireworks extensions, you’ll know that Aaron Beall is the Fireworks extensions guy. In my limited experience using it, it seems to work pretty well.
  • Illustrator CS5 HTML5 Pack: This add-on for Illustrator CS5 extends its SVG capabilities as well as providing some initial support for HTML5 and CSS3.
  • Inkscape: An open-source vector graphics editor with capabilities similar to Illustrator using the SVG file format. You’ve probably heard of this, but I think it merits mention.
  • This chart will give you an idea of the current browser support.

Hope this compilation will be useful to someone. Drop me a line if I’ve missed something —