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.
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).
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.
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.
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…
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.
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.
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?
0420 230 997