Jordesign: Websites for Churches & Ministries


Responsive Breakpoints from the Content Out

Posted on 30/12/11 in Websites

There’s been a lot of buzz over the last couple of days about the increasing number different screen sizes on Android devices, and what this might mean for the future of the breakpoints we use for responsive sites. In particular Stephanie Rieger brought up the topic, and then Jeffrey Zeldman weighed in with his thoughts got some serious discussion going on in the comments.

Responsive break-whats?

As a bit of a refresher – responsively designed sites usually set a series of breakpoints (using Media Queries) where the layout changes at a particular page widths. In most cases these breakpoints have been decided upon based upon the screen widths of common devices (predominantly the iPhone, iPad etc).

A Content First Approach

In the comments of Zeldman’s article, Paul Robert Lloyd has the following to say.

 I advocate using breakpoints that take their lead from the content (again, content first). For example, a design doesn’t adapt because the viewport has narrowed, but because a certain line length becomes excessive, or a long heading takes up too much space.

In very eloquent fashion, Paul has managed to crystalise some of  the thoughts that I myself have been having over the Christmas break.

Keeping things fluid

Ideally, a responsive site should be at least partially fluid as well. That is to say, in between the different breakpoints, the design expands and contracts to fill the available space. This means that at whichever screen size or viewport you view the site, the design should be mostly optimised for that view.

With the knowledge that the content is liquid and will flow to fill the page in between our breakpoints we are given a new freedom. Instead of being bound to creating breakpoints that are targeted at an iPad held in landscape, or a netbook – we can start to create breakpoints dependant in what the content and the design require, safe in the knowledge that even if screen sizes fall in between, the design will still work.

Content Based Breakpoints

This allows us to start using breakpoints to shift and change layouts as the content needs. Paul uses the example of adapting because of line length or heading size. These are great examples, but are just the tip of the iceberg. We can adapt to break out header elements as space becomes available, and have more control over our image sizes rather than have them dictated by a device width.

I’m still formulating exactly what my thoughts are on all the practical outcomes – and obviously haven’t had a chance to try it out too extensively yet, but I am excited to give it a try and see how it works out.

I’ve also a few accompanying thoughts as well…

Pixel or Em Based Breakpoints

There’s an accompanying argument for setting our breakpoints in Ems rather than pixels. This ensures that your proposed layouts will continue to sit nicely whether the user has their font size at the default setting or scaled up or down.

On thinking about it, this is also a great way to do things but, I think, a decision that doesn’t necessarily impact whether you base your breakpoints on content or device.

Letting go of control

There is a mindset you really need to be in to embrace moving away from device-based breakpoints. You need to let go of control. No longer are you crafting perfect designs for iPhone, iPad, Android, browser etc. You no longer dictate exactly how a given device will show the design, but rather trust that the overarching decisions on where the layout should change will flow through appropriately in those devices.

This is merely a case of embracing the inherent flexibility of the medium in which we work, rather than fighting against it.

Time to try it out

Now that the thought of basing breakpoints on content rather than device is in my head – I need to try it out to see how it works in the real world. I’ll let you know how it goes.

What are your thoughts on basing your media query breakpoints on content rather than device?



  1. I think breakpoints should always be based primarily on what the content and design looks like. When it starts looking awkward, add a breakpoint and change some CSS! That’s the approach I took in the media queries chapter of Stunning CSS3, and I think it works well in the real world.

    That being said, I don’t think you should completely ignore common device widths when deciding where to make your breakpoints. For instance, if you know you’re going to have a good chunk of your audience on iPhones, make sure that the design looks particularly polished at 320px and 480px, and if it doesn’t, you may choose to adjust one of your content-based breakpoints a little bit up or down to fix that. The liquid layout then fills in the gaps, as you said.

    13/1/12 at 2:43 am

  2. […] seen it before. The key point is that breakpoints for media queries should be based on when the content needs to change and not because there’s a device out there with a screen of a certain […]

    6/8/12 at 10:30 pm

Leave a reply