Responsive & Mobile Web Design

The Confusion

Responsive and mobile is not always the same thing. Certainly mobile should be responsive, but responsive does not always translate to mobile. For example, Colly is a beautifully responsive website, but it is not so mobile as you might think. Here's a presentation by Bryan Rieger of Yiibu that drives the point home.

I highly recommend reading every article found in this document. Yes, it's a lot of reading, but all very, very worthwhile. The world will be a brighter, happier place if we are all on the same page in regard to mobile design and development.

Keep in mind all this mess is a result of IE7, IE8, hundreds of randomly sized mobile devices, and one WebKit bug.

Many Thanks

These are just some of the folks whose wisdom, brilliance and experience make responsive web design even possible. Their work represents industry best practices and workable, though not perfect, solutions to very challenging cross-browser and cross-device issues.

Where to begin? HTML5 Boilerplate

Begin with HTML5 Boilerplate (mobile or standard) and read the documentation. It provides an excellent cross-browser foundation upon which to build any website. Keep in mind that mobile boilerplate contains mobile-specific modifications not found in the standard version. In addition to many HTML and CSS best practices there are some important baked-in components of H5BP to understand:


Gives you finer control over the user experience through JavaScript-driven feature detection. This is done through media query tests and the built-in YepNope.js micro-library. Modernizr enables a developer to use pure CSS3 selectors by dynamically writing the vendor-specific prefixes for you (e.g. -o-, -webkit-, -ms-, -moz-). No more bothering with vendor prefixes. It also negates the need for conditional stylesheets as the browser-specific styles can be written in one stylesheet, thus fewer calls to the server. For example:

.container { padding: 1em; margin: 1em; }
.ie7 .container { padding: 1em; margin:0; }

IMPORTANT: Be sure to use a customized Modernizr script for faster load time. You don't need Modernizr to detect every feature if you are sure to be using only a few. A customized script could save you 20K. Any savings is good for mobile.

HTML5 Shiv

The de-facto way to enable use of HTML5 sectioning elements in legacy Internet Explorer. And by legacy I mean IE7 and IE8. Otherwise IE won't recognize the new HTML5 elements, such as header, article or footer.


A media query polyfil that enables older browsers (IE6-8) to use media queries.

IMPORTANT: As of version 3.0 HTML5 Boilerplate no longer includes this script by default and so must be installed manually (simple copy/paste, add script reference). Highly recommended.

H5BP Build Script

This too is not included in the latest download of H5BP and is purely optional. You must download it separately. Run the build script to compress images and minify scripts to increase performance. However, keep in mind that images are normally optimized during development. With this being the case the build script simply becomes a minifying tool, which may or may not decrease file sizes significantly.

IMPORTANT: If you use the script it requires Java JDK and WinAnt installed and it would be very wise to understand how to exclude files/folders from the build.

ALSO IMPORTANT, as of 3/8/12 there is an unresolved bug which prevents the default "ant build" function from editing/updating the HTML with newly minified and renamed CSS and JS files. Therefore you must use "ant buildkit" at the command line, rather than "ant" or "ant build".

Set a responsive foundation with Font-sizes

To achieve cross-device success you'll need Ems and percentages. The default font-size for nearly every device is 16px and so 1em = 16px. However, to make your font-size calculations a bit easier set the html/body font-size to 62.5%. This will reset the default font-size to 10px and will allow you to more easily determine font-sizes in EMs. Examples:

  • 0.6em = 6px
  • 1.6em = 16px
  • 16em = 160px

Here's the tricky part about the EM. Nested font-sizes.

The tricky thing about font-sizes set in EMs is that EMs do not represent a specific size. They are a proportion relative to the font-size of the parent container. Nested font-sizes can get tricky. If you create a box within a box within a box and each box has a set font-size then each font-size is relative to its parent container which is relative to its parent container which is relative to its parent container. It is a recipe for madness.

The thing to keep in mind is that EMs are essential to a quality responsive and mobile website.

The best approach is to target text elements within containers rather than the containers themselves. And so where you once would've written

#left_column { font-size: 1.2em; }
Instead write
#left_column p, #left_column ul { font-size: 1.2em; }

Fluid and responsive designs.

First, designing and building a fluid website that is responsive from desktop to mobile can be a very tricky and labor-intensive project: in both design and development. Both design and development face the challenge of not shooting themselves in the foot. Designing or building without allowing for the needed flexibility can lead to a lot of pain and suffering and late nights. And so with that in mind it may be worth considering the design of two versions: one fixed-width layout that will suit both desktop and iPad and then another fluid layout which will serve smaller mobile devices. Of course the downside of such a plan is the management of two sets of content or the construction of a CMS to server both websites.

While a hard-pixel design with multiple breakpoints, commonly known as an adaptive layout, may be used to accommodate mobile devices (see and resize your browser) its device coverage is not as great as one might think. Media query breakpoints have typically targeted popular or common screen resolutions and with the undesired side-effect of creating gaps in which less common device resolutions do not neatly fit into the breakpoint scheme. Here's the Yiibu presentation (Rethinking Mobile) again to drive the point home.

A fluid design will fill in these breakpoint gaps by flexing from the lowest to highest resolution. But again, a fully fluid layout is a tricky beast to tame.

Here are some other important considerations:

  • Grids: It may be best to build your design upon a 1000px grid. This will allow for much easier calculations of width percentages than a 960px grid would. For example, 60% of 1000px is 600px, but what is 60% of 960px? Time to get out the calculator. Of course this assumes a fluid design in which the max-width has less importance. The majority of people can accommodate this width even if it isn't a fluid design. If it is fluid then the size of the original design doesn't matter so much.
  • Page Container Width: Set the max-width of the page container in Ems to avoid a bug in WebKit.
  • Inner Container Widths: Percentages should be used within the context of a max-width container. This is to allow for a more easy conversion to mobile. Start off with percentages and you won't have to change as much when crafting your media query styles. For example, once the layout is constrained to a single column layout a 100% container width will accommodate many different devices, whereas a pixel width or Em width would need to be continually adjusted for a variety of devices. Just for reference I would recommend commenting the original pixel sizes besides your percent conversions.
  • Background Images: Consider how the fluid layout will accommodate background images. Background images cannot be resized just like in-line images. Yes, true, there is a CSS3 background-size selector, but desktop browser support is very poor.
  • Modularity: Construct the website content as modularly as possible so the conversion to mobile is easier. Why? There will be circumstances when a minimal HTML structure will lack the containers or elements to target and control content as the layout flexes. This is especially true with floated elements.
  • Padding: Normally you wouldn't want to mix PX with percentages, but creating consistent padding in percentages can be tricky. However, padding in PX can be used for children of percentage width containers, but DO NOT define the child's width otherwise it won't work. And this will only work with block-level elements. Here's an explanation.
  • Borders: may be set without recalculating widths by using outline: 1px for borders when using percentages. But keep in mind that this creates a border around the entire element. You cannot use this styling for top or bottom borders.
  • CSS3: can make a fluid layout much easier to construct, unless of course your clients are predominantly government and entrenched in IE7. If that's the case forget I said anything. Pretend CSS3 does not exist.
  • Scripts: Beware of scripts that set widths to its content. This may not convert to mobile layouts. Perhaps it could be changed dynamically? I don't know. Please consult your local JavaScript master.

Go mobile with media queries.

Always use EMs for media query break points. Why? Here's a great article on media queries and Ems. Basically, if you don't use Ems for your breakpoints your layouts will go to hell when people increase the font-size on their browser or when they zoom.

IMPORTANT: Always use stacked media queries otherwise WebKit will download ALL visual assets referenced under every media query even if it does not apply! Below are some stacked media queries.

@media all and (min-width: 36.13em) and (max-width: 49.0625em) { …styles here… }

@media all and (min-width: 31.065em) and (max-width: 36.125em) { …styles here… }

@media all and (min-width: 21.065em) and (max-width: 31.0625em) { …styles here… }

Hide content via media queries?

One might think that you could hide unnecessary content from mobile browsers using CSS and media queries. Not so fast. Read these results to media query and asset download tests. The better thing to do is to reveal content at higher resolutions with conditional loading. See below.

Conditional loading.

Conditional loading allows you to omit unnecessary content for lower resolutions and then reveal it for higher resolutions. For example, large callouts for tertiary services may be valuable for the desktop or iPad, but it may be completely inappropriate for mobile. Conditional loading determines what gets displayed under what context. Naturally this requires the use of JavaScript.

Adaptive/responsive images.

Adaptive Images uses PHP and media queries to dynamically generate images for different target resolutions rather than manually creating sets of images for every eventuality. This is especially good for sites using a CMS. However, this is not to be considered the perfect solution, but rather the best solution under the present circumstances. For a deeper explanation: Adaptive Images for Responsive Designs.

Another alternative is Responsive enhancement which defaults to a smaller mobile image, detects is the display requires a larger version and then switches out the source dynamically to provide what's needed. Make sense? Here's an explanation that isn't much more than I've already said.

And yet another alternative is PictureFill by Scott Jehl which is a Responsive Images approach that you can use today, that mimics the proposed picture element using divs, for safety sake.


Honestly, I don't fully understand what imgSizer does or how it works, except that it fixes display problems with IE7 resizing images.


FitVids allows embedded video to resize cross-browser.

More Reading

The links below have been sorted according to foundational topics down to helpful tools: sort of. It's all worthwhile reading that will help to inform your design or development, whichever is your thing.

Photo of Jeff Fisher wearing knit hat.
Myself in winter.

Jeffrey Brian Fisher

Whether the medium is Photoshop, HTML, CSS, wood, or pastel there is nothing more satisfying than having crafted something well.