I used to use respond.js to make IE8 media query-friendly, but that script stopped working for me suddenly last week in WordPress. I still don’t know why, but after several hours of trying to fix it I realized that I really didn’t need to. Why was I worried about media queries in IE8 anyway? I really wasn’t – my real concern was that I was serving the mobile-first styles to that browser instead of the desktop styles.

But I’m using Sass – have been for a few months now, I love it – and Sass makes it easy to deal with that problem. It’ll help you create desktop styles, sans media queries, and serve those exclusively to IE8 via conditional comments.

I found some good references for how to do this, but I was so frustrated by that time (it was late and I’d been banging my head on the desk for an hour or two) I had a hard time getting my head around any of them. Once I finally got it, it was an ‘aha’ moment! I’m writing this post in hopes that I can make it super-easy for you to use this technique if you’ve recently had a frustrating time with IE8 too.

Compass and Breakpoint

You’ll need to use Compass and the Breakpoint extension for this tutorial. Breakpoint is a Sass mixin that makes it easy to write media queries – learn more about what Breakpoint does here.

Get Breakpoint going by first installing it:

Then if you’re starting a new project with Compass, you can require it now:

Otherwise you’ll need to add this line to your existing config.rb file in your project folder:

Finally, you’ll need to import the Breakpoint partial into your style.scss file (after you import Compass):

And you’re ready to go.

Creating the Media Queries and IE8 Fallbacks

In your utility partial, or maybe in a variables file, add a media query using Breakpoint. It will look like this assuming we want a min-width of 760px:

(Read the examples here if you want more details on the different kinds of media queries you can use).

Now normally you’d use this in your .scss files like this:

And that produces this compiled CSS:

But because we want to take care of old IE by not serving the media queries to it, you’ll first need to add this new mixin to your utilities file (wherever you’ve put the Breakpoint media queries):

And then instead of the @include snippet above, you’ll use this one in your .scss files:

So instead of ‘@include breakpoint($grande)’ you’re using ‘@include grande.’

If you look in the compiled CSS file you’ll see this:

And then, you’ll just need to enable the .ie8 class for IE8 by using this conditional comment in the head section of your site:

Now IE8 will see your width styles and you won’t need to worry about it not seeing the media queries anymore. Sweet!

What you’ll want to do is create one of the new mixins for each breakpoint you add – so if you have 5 breakpoints, you’ll have 5 new mixins.

This works so nicely, and no need for any special Javascript to force IE8 to be mq-friendly. I hope you found this tutorial helpful!



After Denver WordCamp back in November and a really well-done presentation by Jeremy Green, I decided it was finally time to dive into Git.

As a mostly-solo developer, I’ve felt ambivalent about it, but I know that it’s very important, if not critical, when working with a larger team. So…

I got my OS version of Git here. I’m not much of a command-line person so I also checked out some of the GUIs – the one that I liked (not knowing anything about it yet except that it had a pretty nice UI) was SourceTree from Atlassian. Jeremy had talked about BitBucket being a good choice for hosting private repos, and Atlassian also makes BitBucket. Seemed logical.

Then I looked at some resources and started with this one: TryGit. I liked ts friendly UI and the step-through examples, it was easy to get going but it quickly got into more advanced areas (I’m not there yet). This was a good starting point.

So in the next WordPress project, I resolved to just jump in and do this. Note: this is super-basic – I’m only using this on my local machine at the moment, so bear with me. This is for total newbies.

I opened up GitBash (the included SSH editor), navigated to my project folder and typed in:

This creates a fresh new repository (repo) of project files.

Then I’ll work on stuff for awhile. I can check out what’s happening with Git by typing:

This will show me a list of all the files in my project that have either not been added to Git, or have changed since the last time I added them. To add a file to Git so that it’s monitored, type:

But it’s easier to just add all the files at once:

Then check status again and you’ll see a list of files that are staged – they’re ready to commit, which means adding them to the repository. To commit all the files in staging:

Name your commits anything you like, just make it descriptive. You can view all your commits with:

Then I work some more, and when I get to a point where I feel I can give my commit a different name (i.e. I’ve finished a task), I type:

And so on. That’s it – very easy, not too intimidating with the command line, and you’ve removed so much risk with just these simple steps. I actually haven’t used the SourceTree GUI yet – for what I’ve done so far, I’m now happy with the command line.

Now that this process has become fairly automatic for me, my next step is going to be setting up a remote repo, probably with BitBucket, and learning how to do those parts of Git. And how to make branches.