Perfectly Framed, Responsive Images

Look at this cat. This image of my cat is the crux of this entire post. Now resize your browser and watch what happens (spoiler alert: the image resizes intelligently).

Update: If you’d rather see an animated demo, then check out this CodePen.


The Goal

When I revamped this blog, I had some very specific criteria in mind for how I wanted to present images, much of it with regard to responsive design. Slapping width: 100% on my images wasn’t good enough.

  • Images must be centered and nicely framed with a border and shadow.
  • Space permitting, images must display at their original size, without stretching.
  • Images can never exceed the width of the space they’re in. No overflow or cutoff.
  • If an image were to exceed the width of its container, it must scale down to fit.
  • All of this must work whether or not the image is wrapped in a link tag.
  • No JavaScript. window.onresize? Gross.

The Solution

Fortunately, I was able to achieve all of this with a single wrapper div and a modest amount of CSS. You already saw the solution in action when you resized your browser.

Here’s what the HTML looks like:

And here’s the CSS:

I won’t bore you with a CSS line-by-line, but the basic idea is to use width and max-width in just the right combination, while box-sizing: border-box prevents the added border pixels from throwing off the widths. Centering is done with text-align: center and display: inline-block.

Takeaways from Breaking Development 2012

Breaking Development 2012 logo

I went to the Breaking Development 2012 conference in Orlando last week. There were a lot of great topics about the evolving mobile landscape, responsive web design, and content delivery. This is my (longer than expected) overview of my takeaways from the conference. Brad Frost has some great notes on the individual sessions, which I’ve linked to at the bottom.

Content Is King

It’s all about content. To be successful, you have to deliver good, valuable content. A slick website is great, and a slick app is great, but don’t lose sight of their purpose. They are simply interfaces to your content. “Build an app” is not a business strategy, as this alone means nothing.

Once you realize that it’s about the content and not the interface, then you start to see content as a device-agnostic commodity, which is very much aligned with the current evolution of the web. Read on…

The Device Landscape Is Changing

Mobile web usage is expected to exceed desktop web usage within 2 years. Many people use their mobile devices as their primary access to the web. 28% of mobile web users never or rarely use desktops to access the web. The perception that mobile users only want a limited, scaled-down experience is simply not true. For example, eBay sells 2,500 cars per week via mobile devices. We can no longer segment mobile users off into a second-class category.

It’s Not Just Mobile

So, yes, we need to cater to mobile devices. A lot of companies already know this. But to be future-proof, you have to think even further. Remember when browser sniffing was commonplace on the web? This tactic was sustainable when we only had 2 major browsers to worry about. But with 5 major browsers today, this is just not practical.

History is repeating itself with devices. We used to be content with just desktop and smartphone support. But recent years have seen a surge in tablet usage. And now there are web-enabled TVs on the market. Cars and gym equipment are web-enabled. The list is growing.

So what can we do to prepare for this “impending zombie apocalypse” of devices? To me, this is better asked as 2 questions: How do we get our content to all these devices? And how do we keep up with creating interfaces for all these devices?

Create Once, Publish Everywhere

How do we get our content to all these devices? In a word (or 3), APIs. Put your content into a single source, then use APIs to share to all your applications. Furthermore, opening your API to the public could yield unexpected bonuses. NRP adopted a “create once, publish everywhere” philosophy when creating their public APIs and saw an 80% increase in pageviews as a direct result.

Of course, there’s more to it than just “make an API”. Your content needs to be well-suited for it. This means having clean, well-structured data that is platform-agnostic and completely disjointed from your presentation layer. It must be truly portable.

Responsive Web Design

How do we keep up with creating interfaces for all these devices? There is no absolute answer to this question, but there is a really popular one: responsive web design. A single well-crafted responsive site can serve any device, on any platform, with any sized screen, as long as a decent browser is installed. All with a single code base, without having to learn platform-specific programming languages.

Responsive web design is not the undisputed solution to every problem ever, but it does show a lot of promise as a cost effective and highly sustainable option.

Session Notes

As promised, here are Brad Frost‘s notes by session:

There are 2 more sessions that didn’t have notes, but the slides are posted online:

Making Coder’s Block Responsive

Coder’s Block v4 was my first full responsive web design project. The concept and basic mechanics of making a site responsive are simple enough, though a lot of my expectations and assumptions changed during the project. Responsive web design is definitely an art, and I have certainly not mastered it in one try. That said, I wanted to write about my experience and what I learned from it.

I’ve mentioned responsive web design before (here and here). I won’t rehash an introduction, but if you’re new to the subject, then I highly recommend the obligatory article over at A List Apart.

For visual context, here’s a single page from Coder’s Block v4 as viewed in mobile-sized, tablet-sized, and desktop-sized windows:

Coder's Block v4 responsive mobile screenshot
Coder's Block v4 responsive tablet screenshot
Coder's Block v4 responsive desktop screenshot

Notice how all three show the same content, but with differing layouts that are appropriate for the space available? Hooray for responsive web design! Alright, moving on…

Mobile-First or Desktop-First?

Responsive web design depends on CSS media queries to dynamically apply styles as the viewport changes. For example, as in the screenshots above, your page might be a single column layout in a smaller viewport (mobile), but become a 3 column layout in a larger viewport (desktop).

There are two ways to approach this: mobile-first and desktop-first. With mobile-first, you start with your mobile layout and then add styles to it when the viewport gets bigger and needs to be filled out more. This is done using min-width in your media queries to specify the pixel-width “breakpoints” that trigger the additional styles.

Here’s an example that makes header text bigger once the viewport is at least 640px wide:

Desktop-first is just the opposite and uses max-width to specify breakpoints as the viewport shrinks and the layout needs to be reduced.

I started with desktop-first because I already had a desktop layout in mind. Some would say this is wrong, that mobile-first is better because it forces you to distill the layout and focus on what’s important in it. I don’t necessarily disagree. I did end up switching to mobile-first, but for a different reason: the CSS. Conceptually, adding CSS to increase a layout made more sense to me than adding CSS to reduce a layout.

No Universal Breakpoints

I originally decided on three nice, round, mathematically significant widths to serve as my breakpoints: 320px, 640px, 960px. I then tried to force all responsive style changes into only those three breakpoints. That simply didn’t work. What I learned is that the breakpoints you choose depend very much on your particular layout. Don’t be afraid to use whatever numbers you need.

The Full Spectrum

Another fallacy is to fixate on pleasing very specific viewport sizes. This is very much against the spirit of responsive web design. Your site should look good on the full spectrum of pixel widths, not just the ones that line up with popular Apple products. Furthermore, you may find a stray scrollbar throwing off your carefully chosen breakpoint, but if you have the full spectrum covered, your site will still look good despite that unexpected -20px.

Prepare for Math

I used a percentage-based 12 column grid layout, as many people would recommend. The 960 grid system didn’t quite have the column to gutter ratio I wanted (I wanted bigger gutters) so I crafted my own numbers. On top of that, I also had some places with nested columns, which meant accounting for multiplicative percentage width divs. All of this to say… There was an unbelievable amount of math involved. Here’s a screenshot of the Excel spreadsheet I created to get all the numbers right:

grid formulas

I don’t feel like reliving all that math here, so I won’t go into detail. But maybe one day I’ll share the spreadsheet (and its formulas) that I came up with, as I found it incredibly helpful.

Not Everything Scales

Going into this, I had the impression that pixel measurements were absolutely forbidden. Every width had to be a percentage so it could scale with the viewport. Well, I ultimately decided that this wasn’t the best advice. Things like mini-icons, single pixel borders, and some spots of padding looked best at fixed values, regardless of the viewport size. It’s all about good judgement.

It’s Fun!

When all the pieces fall into place, and your sites renders beautifully on any device, you feel like a wizard. Making a layout responsive is definitely harder. It feels like you’re playing with multi-dimensional CSS. But the payoff is very nice indeed.

Coder’s Block v4

I am happy to announce that Coder’s Block v4 is finally live. Coded in .NET 4.0 MVC 3. It took me a ridiculous amount of time (4 months!) to make. I guess that’s what happens when you have a personal project with no deadline and an endless stream of tangents to go off on.

CBv4 is going to be a big source of blog fodder for the coming weeks. I learned a lot of new tricks and built a couple nifty things that I really want to share. But for now, I’ll just give some highlights.

Responsive Web Design

The entire site was built using mobile-first responsive web design. This means that every page is naturally mobile friendly. When more screen space is available, the pages will automatically adjust their layouts for a better viewing experience. Go ahead, open any of the pages in a desktop browser and then resize the window to be bigger or smaller. You’ll see what I’m talking about.


One of my earliest ideas for CBv4 was to pull my activity from various sites around the net and show them in a single combined “super feed”. I built my own custom solution to do exactly that. It runs as a continuous server-side process, grabbing feeds and mixing them together. This is something I plan to release as open-source very soon.

Update: Super Feed on GitHub.

Social Icons

I decided to try my hand at making my own social icons. You can see one set I made in the super feed, and another set in the footer. I crafted them using Illustrator and Photoshop. Eventually, I want to add a few more icons for other popular sites and then release both sets for free.

Update: Mini Social Icons on Dribbble.

Image Fix

Some images on the site (like my Flickr photos in the super feed) needed to be dynamically scaled and cropped to fit into the layout. So I whipped up a little utility that could do this on the fly. Simple, but very useful. This is also something I plan to open-source.