I’m going to assume that if you’re a designer (or developer) by profession and you work in the web industry, you’ve already read Ethan Marcotte‘s absolutely fabulous tome “Responsive Web Design” and understand the basics of writing CSS for multiple screen sizes. If you haven’t, stop reading now and go buy that book. It’s a couple years old and things have advanced since then, but the fundamentals remain the same: No fixed widths, use flexible grid, keep media fluid and take advantage of media queries for shifts in layout.

As helpful as Ethan’s book (as is the case with many others), I’ve done more than a few responsive projects and keep running into the same pain points that I haven’t seen discussed in a single place. That’s surprising as they have proved to be the difference between excellence and mediocrity. I’m sure you probably have additions to this list, but this is the one that I’ve gleaned from my experience.

Friends Don’t Let Friends Reinvent the Grid

I’m as interested in craftsmanship and striving for excellence as the next guy, but the idea that you can’t re-use a system someone else invented for your work to be ‘craft’ is misguided. A furniture craftsman shouldn’t reinvent the saw anymore than you should reinvent a grid system. Honestly, I need to focus my attentions and effort in other places rather than keeping track of column widths and struggling with getting layout right. I expect to get a flexible grid for free and CSS layout to be easy and quick. I’ve been using Susy for a couple years and find it to be the most agile grid system around. All your columns are abstracted and independent of crufty class names. Their documentation isn’t as thorough as some would like, but the basics are easy enough to understand. Set context, define the columns your element will span, and make sure the last element in a row doesn’t have right margin. The developers of Susy have strived to keep it pretty simple and they’ve succeeded.

Don’t Complicate Your Life, Make Retina Easy

Look at the growing marketshare of mobile devices with retina-calibre screens; neglecting to build new projects without a high resolution GUI is shortsighted. Thomas Fuch‘s book on “retinafying” interfaces for the brave new world of pixel dense backlit screens is an excellent resource. The key is to keep things simple. There are intricate javascript solutions that swap out images based on screen resolution. Those are great if you have the time and budget to implement them, but if you don’t, there are simpler roads to beautiful retina sharpness. First, avoid PNGs were you can. They are large files that suck up bandwidth on smaller devices. Yes, there are moments when you need an image with a transparent background. You double the size of the PNG, you set background-size to 100% and retina goodness is yours. But in this instance, use SVGs where you can. SVG, when constructed properly, are incredibly small files and are completely pixel independent. What about those browsers that don’t support SVG rendering? Well, coincidentally, those browsers also don’t support multiple background images. If you need to support legacy, add a small PNG as the first background image and an SVG as a second one. Newer browsers (like those in devices with retina screens) will use the SVG, older ones will pull down the PNG. Kudos to Ben Schwarz for pointing this out! Make sure your photographs are double-sized, low resolution jpgs. Size them down to the desired size and you’ll see that they actually look really good on high resolution screens.

Inline Images ♥ max-width

There are a bunch of heavily used websites out there that are responsive or have mobile versions that repurpose content. It is always surprising to me to see inline images that haven’t had a max-width of 100% set on them at a global level on prestigious websites. It’s a great rule that you can just set and forget, knowing that those inline images will never flow out of their containing element at different widths.

Horizontal Sizing Can’t Come Through CSS Alone

Matching heights on elements in a row can turn into a pretty major headache. I’m a designer and I understand the appeal of having a nice clean row of elements in columns. That isn’t easy to implement when dealing with a fluid layout. On a recent project, each element also had to have a call-to-action button at the bottom. However, the content within the element needed to be dynamic. At that point, CSS alone isn’t going to help you get those articles to have equal heights across the row. You could give them each a static height, but that’s not dynamic or sustainable over time. Although it is a couple of years old, Stephen Akins’s jQuery plugin worked great for me. It will give an inline height to all the elements in a stipulated row, adjusting their heights to whichever element is the tallest. The plugin acts on document ready and on page resize. We had to do some small adjustments to the plugin to get it to work properly on resize. One major caveat is that this plugin won’t work on elements that resize after the DOM loads (accordions, etc). All of this will probably get better as the W3C spec for flexbox gets more fleshed out. Can’t wait!