What is Mobile First CSS and Why Does It Rock?

We throw around the phrase “mobile first” a lot here at MIGHTYminnow. It factors into many of our discussions and plays an important role in pretty much every site we build. We even created the Genesis Mobile First Child Theme, which is dedicated to making it as easy as possible to go mobile first when working with the fantastic Genesis Framework. Well if you’re wondering what “mobile first” means and why it rocks, keep reading.

What is Mobile First?

Lots of different people define mobile first in lots of different ways, but when we talk about building a mobile first website it basically boils down to two things:

1. Philosophically: Optimizing the experience for mobile users as much as possible. In other words, putting the needs of mobile users first.
2. Codily (we just made that up): Writing CSS in such a way that smaller (mobile) devices can access their styles without having to wade through styles written for desktop devices. In other words, writing the mobile styles first. (“First” means before the media queries that define the look of the site on larger displays – media queries are one of the hallmarks of “responsive design.”)

Now, there are tons of considerations that go into making this magic happen, and we’ll get to that in a minute. But first things first. . .

Why Go Mobile First?

There are a few key reasons why mobile first development is a good idea:

1. Mobile traffic is growing. . . fast
   The number of website visits coming from mobile devices is ever-increasing, and is predicted to surpass desktop visits in 2014. Bottom line: mobile viewership is growing and so is the demand for mobile-friendly websites.
2. Mobile experience ≠ desktop experience
   Phones and tablets are different from desktop machines in so many ways (screen real estate, processing power, connection speed, etc), and their different limitations and capabilities warrant different solutions. Bottom line: designing for ALL devices, and coding in the way that makes the most sense for each of them, is better than designing only for desktop devices.
3. People will leave and never come back
   Tons of folks have written on the negative effects of poor site design/functionality, particularly in regards to site speed. Bottom line: if your site doesn’t work well on mobile, you’ll lose users.

How Do I Code Mobile First CSS?

There are tons of ways to optimize mobile users’ experience, and if you’d like to learn more about all of them you should definitely check out  Luke Wroblewskis’ excellent book: Mobile First. In this post, however, we’re going to focus primarily on CSS – our bread and butter. With that in mind, here are some mobile first CSS best practices we use on a daily basis:

Min-Width Media Queries

This is probably the most common question we get when talking about mobile first: why does it matter whether I use min-width or max-width media queries?

Using min-width media queries at the end of your style sheet means writing all of the common (meaning used by all devices) CSS first. All of the rules that you want phones and tablets to see are front and center, with larger screen caveats in the media queries below, in order of increasing screen size. Writing the common-to-all styles first ensures that mobile styles get loaded without desktop styles mixed in – which can significantly improve the mobile experience.

Mobile first CSS is written like this:
Styles for mobile and styles that are common to all screen sizes
(no media query)

Media query with a smallish min-width breakpoint
e.g. @media (min-width: 400px)

Media query with a slightly larger min-width breakpoint
e.g. @media (min-width: 600px)

Media query with a  larger still min-width breakpoint
e.g. @media (min-width: 960px)

One way to think of it is that you start with a mobile base and build up (or out, if you think in terms of widths).

It seems like, with the introduction of responsive design, that a lot of folks defaulted to building the desktop version of their site first, then proceeding with max-width media queries at the bottom of their CSS in order to “undo” these desktop styles for mobile devices. You’ll see this approach used in TONS of responsive WordPress themes. We think this is because we’ve gotten so used to visualizing design from a desktop-first standpoint. “I’ve got my big screen, and as I shrink it down to tablet and phone sizes I need to know the maximum width up to which I should apply my mobile styles.” That’s thinking desktop first – essentially catering to desktop machines and treating mobile devices as an afterthought.

But here’s the catch. Let’s say our style sheet is massive (although in an ideal world we would minify and concatenate all our CSS), and our media queries are at the very bottom (which is good). Writing the desktop layout first – float this, position that – and then undoing that floating, positioning, etc in the media queries means that you are first building your desktop layout, and then deconstructing it for mobile. To do this, you are writing more code, and doing it in the order that makes the least sense to the devices that need the most help in terms of connection speed. And if you’re viewing the site on your phone, you’re going to be seeing the desktop version of the site until the CSS is almost entirely parsed. We’re not talking very long here, milliseconds at most, but we’ve seen plenty of sites on which this moment of incorrectly-styled content is visible – and distracting. You can read more about this eternal nemesis of developers the world around: FOUC.

Using min-width media queries allows you to build your design from mobile sizes on up, thus shifting the burden onto non-mobile machines. Now we’re catering to the limitations and capabilities of different devices (non-mobile devices typically load/render CSS faster than their mobile counterparts). Historically, the trend has been that mobile devices have less processing power than their non-mobile counterparts. While this gap is shrinking, why not make sure the less performant devices get their CSS faster?

The other reason to use min-width media queries is that it really helps us get in the mindset of. . .

Progressive Enhancement

Progressive enhancement essentially means adding more cool stuff (CSS & JavaScript, usually) as our device can handle it. It’s sort of the inverse to the concept of “graceful degradation,” which means that we start with all of our great functionality and design components, and remove them as needed for devices/browsers that can’t handle them. In terms of taking an approach to mobile first CSS, we can often achieve better performance on average by implementing a mobile first approach. Again, remember that we want to switch as much of the work as possible away from mobile devices and onto their (typically) more performant non-mobile counterparts.

So we start with the simplest core features, and we add more as the user’s device can handle it. This not only helps us follow our favorite KISS practices, it also results in better performance and user experience.

Content (Not Device Width) Determines Breakpoints

I can’t tell you how many sites we see with the following breakpoints: 320px, 480px, 768px, 1024px. As you may have noticed, these are the exact dimensions of the ever popular iPhone (pre 5) and iPad. The folks that wrote this CSS had one thing in mind: making sure their breakpoints aligned perfectly with specific devices. But what happens when a new device with new dimensions is released, the iPhone 5 for instance? Or a new Android tablet or the MS Surface? Suddenly our breakpoints don’t make as much sense and we’ve got to modify our CSS to accomodate these new dimensions. New device. New media query. New device, New media query. On and on, ad infinitum. You can see there is a fundamental problem with letting popular devices dictate breakpoints.

Instead, we prefer to base our breakpoints on the natural qualities of our content – essentially paying attention to when each element “wants” to be restyled. A great example of this is styling navigation menus.

On the MIGHTYminnow site, our navigation appears as a grid on mobile devices (try dragging your browser window to a smaller width to see). As the screen size increases, we simply pick a point at which the content itself would look better in a new formation, and that’s our breakpoint! We keep working our way up until we’ve reached desktop size, and that becomes our final min-width media query. It’s pretty simple, really, and we’ve created CSS that is future-proof, ready for any device size. Honestly, this organic approach flies in the face of a lot of the current grid-based frameworks and theories, but it is really the only thing that makes sense to us – plus it’s really not that hard to implement. If content is king, why not let your content define the point at which your layout changes?

Relative Units & Percentage Widths

Mobile first development, done well, is synonymous with flexibility. Using relative units (em or rem) and percentages (particularly percentage-based widths), allows you to create CSS styles that flow smoothly across devices and screen sizes. Almost more importantly, they make future changes that much easier. Imagine, for a moment, that you’ve hard-coded your content-area/sidebar widths and font-sizes with something like this:

@media only screen and (min-width: 1000px) {

	.content-area {
		width: 700px;
		font-size: 16px;
	}

	.sidebar {
		width: 300px;
		font-size: 14px;
	}

}

Seems fine, right? But what if you suddenly realize your media query needs to trigger at 1060px, not 1000px? Now you’ve got to manually change the pixel widths of your content-area and sidebar. Or say you decide you need to bump up all font-sizes across the board. Here we’re just looking at two elements, but imagine the potential impacts on a site with hundreds, or even thousands, of CSS rules. That can get pretty daunting pretty fast. With relative units and percentage-based widths, however, far fewer modifications are needed. The proposed changes above are as simple as:

@media only screen and (min-width: 1060px) {

	html {
		font-size: 10px;
	}

	.content-area {
		width: 70%;
		font-size: 1.6rem
	}

	.sidebar {
		width: 30%;
		font-size: 1.4rem;
	}

}

Notice that we’ve switch our widths to percentages, and the font-sizes to relative values. Now, you can see how our widths will work no matter where our breakpoint occurs, and our font-sizes can be changed across the board just by changing the <html> element’s font-size.

The Little Things

Mobile first CSS is often about improving the little things, which can make a big cumulative difference in the end. Here are some “little” best practices to keep in mind:

• More Gradients & Font Icons, Fewer Images
  If you are looking for some new best friends in the web world, than might I recommend CSS3 gradients and font icons. These methods not only pack some serious design punch, they also help you minimize your HTTP requests and save on bandwidth – surefire ways to improve overall site speed and general user experience. Images, on the other hand, are a surefire way to increase load times and leave your users hanging, particularly on less performant mobile devices.
• Smaller Images at Smaller Sizes
  Serving device-appropriate images is a great way to improve a site’s performance across all devices. With background images, this is a pretty straightforward task. As you move up through your CSS breakpoints, you can simply load larger versions of these images, changing your CSS styles accordingly. For inline images, this can get a bit trickier. The same concept applies (smaller images for smaller devices), but solutions typically require a JavaScript polyfill to dynamically replace/load images as needed. If you’re interested in this method, you might want to check out the following:
  • New Nine Adaptive Images WordPress plugin by New Nine
  • Adaptive Images by Matt Wilcox
  • picturefill.js by Scott Jehl

What’s The Catch?

Mobile first sounds pretty good, right? So why isn’t everyone using it?

Old Habits Die Hard

The good news is that mobile first’s main obstacle is simply that we’re not used to it. For a long time we’ve been designing websites for non-mobile devices simply because mobile devices never played a significant role in viewership. Consequently, we’ve picked up some deeply ingrained site-building habits, processes, and philosophies along the way. A mobile first approach requires us to flip some of these habits on their head (e.g. designing with a phone screen in mind and working up to desktop, instead of vice versa), and this can certainly lead to some growing pains. Worth it? Definitely. I mean, table based layouts weren’t easy to let go of, but we’re all glad we did.

Design problems

“The designer doesn’t understand mobile” or “there’s no budget for extra (mobile) comps”

One thing we’d like to stress is that mobile first coding doesn’t have to mean generating special mobile comps, although that sounds luxurious and lovely. Even if all you have is a desktop design, you can create a great, responsive website (have a look at our case study for Rocket Dog Rescue). We only ever have our designers generate desktop designs, and we use them to make responsive websites. All you need to do, in our opinion, is to be very conscientious when adding widths, floats and other column inducing code. As you are coding your “desktop” comp, isolate any column widths and layout stuff  in media queries at the bottom of the page, as well as any outrageous heading font sizes that don’t look good when you drag your browser down to phone sizes. Do some browser dragging as you go, and pop over to responsive.is or responsinator for validation. If you treat your comp as a guide, and keep on top of the way the site looks on mobile as you code, you can come away with a “pixel perfect” desktop display and appropriate mobile layouts without a ton of additional effort.

Side Note: Polyfill Needed

Alas, certain Browsers-That-Must-Not-Be-Named still don’t natively support CSS media queries, and will need an extra polyfill to accurately render your mobile first CSS. Good thing there are some great polyfills available:

• respond.js WordPress plugin by Romoonus
• respond.js by Scott Jehl
• css3-mediaqueries.js by Wouter van der Graaf

In Conclusion

Mobile first. Learn it. Use it. Love it. Taking a mobile first approach is a great way to ensure that your site looks and performs optimally across the board.

Resources

Mobile First, by Luke Wroblewski
http://www.lukew.com/resources/mobile_first.asp

Creating a Mobile-First Responsive Web Design, by Brad Frost
http://www.html5rocks.com/en/mobile/responsivedesign/

Mobile First Design: Why It’s Great and Why It Sucks, by Joshua Johnson
http://designshack.net/articles/css/mobilefirst/