Fanfare for the common breakpoint

.net Magazine is running a series of articles on their site right now as part of their responsive week. There’s some great stuff in there: Paul is writing a series of articles—one a day—going step-by-step through the design and development of a responsive site, and Wilto has written a great summation of the state of responsive images.

There’s also an interview with Ethan in which he answers some reader-submitted questions. The final question is somewhat leading:

What devices (smartphones/tablets) and breakpoints do you typically develop and test with?

Ethan rightly responds:

Well, I’m a big, big believer of matching breakpoints to the design, not to individual devices. If we’re after more future-proof responsive designs, we should stop thinking in terms of ‘320px’, ‘480px’, ‘768px’, or whatever – the web’s so much more flexible than that, and those pixels are a snapshot of the web as we know it today. Instead, we should focus on breakpoints tailored to the design we’re working on.

He’s right. If we’re truly taking a Content First approach then we need to “Start designing from the content out, rather than the canvas in.”

If we begin with some specific canvases (devices), they’re always going to be arbitrary. There are so many different screen sizes and ratios out there that it doesn’t make sense to favour a handful of them out of tradition. 320, 480, 640 …those numbers aren’t any more special than any other screen widths.

But I now realise that I have been also been guilty of strengthening the hallowed status of those particular pixel widths. When I post screenshots to Flickr or include screenshots in presentations I automatically do what the Media Queries site does: I take snapshots at “traditional” widths like 320, 480, 640, 800, and 1024 pixels.

Physician, heal thyself.

So I’ve started taking screenshots at different widths. For the screenshots I posted of the new dConstruct site, I took a series of screenshots from 200 to 1200 pixels in increments of 100.

dConstruct2012-300 dConstruct2012-600 dConstruct2012-900 dConstruct2012-1200

But really I should be illustrating the responsive nature of the design by taking screenshots at truly arbitrary widths: 173, 184, 398, 467, 543, 678, 832 …the sheer randomness of those kinds of numbers would better reflect the diversity of screen sizes out there.

Of course what I should really be doing is posting pictures of the website on actual devices.


I think our collective obsession with trying to nail down “common” breakpoints has led to a fundamental misunderstanding about the nature of responsive design: it’s not about what happens at the breakpoints—it’s about what happens between the breakpoints.

I think Jeffrey demonstrated this misunderstanding when he wrote about devices and breakpoints:

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

I was surprised that he suggested the long-term solution would be a shake-out of screen widths resulting in a de-facto standardisation:

But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

I don’t think that will happen. If anything, I think we will see even more diversity in screen sizes and ratios.

But more importantly, I don’t think it’s desirable to have a “standard” handful of screen widths, any more than it’s desirable to have a single rendering engine in every browser (yes, I know some developers actually wish for that: they know not what they do).

I agree with Stephanie: diversity is not a bug …it’s an opportunity.

Have you published a response to this? :


On Thursday (26/04/12) the fantabulous Jeremy Keith wrote a short post on common breakpoints in responsive web design where he expands his thoughts on a question asked to Ethan Marcotte in a Q&A article on the .net magazines’s website. Ethan was asked - “What devices (smartphones/tablets) and breakpoints do you typically develop and test with?” His retort can be summed up just by the last sentence of the response - “…we should focus on breakpoints tailored to the design we’re working on.” Where as I completely agree that we shouldn’t be just ‘designing’ sites for specific devices. For me it’s quite hard to not think about how something would look on a popular device viewport. How I like it… As I’m a freelance front-end developer that codes by candlelight I’m sure you can understand I don’t work (well, not yet) on too many really big projects I generally think out most of my designs rather than initially draw a wireframe / open up photoshop. Doing this I tend to ‘think’ how the design would look on my iPhone and my iPad and my MacBook Air (yes, I use Apple products).  Therefore I always start with a ‘boilerplate’ of media queries. They’re aren’t a hard and fast of rules to stick to, just a starting point. Of course the first starting point when coding a design is as perfect as Bryan Rieger puts it The lack of a media query is your first media query So I do all of my basic stuff here, all the typography stuff, things like that before I even get to a media query. Then after that I start designing (well, coding?) with this list of basic media queries -

/* ===== == = === Base Styles === = == ===== /

/ ===== == = === 20em (320px) === = == ===== /

@media only screen and (min-width : 20em) {

/ ===== == = === 30em (480px) === = == ===== /

@media only screen and (min-width : 30em) {

/ ===== == = === 37.5em (600px) === = == ===== /

@media only screen and (min-width: 37.5em) {

/ ===== == = === 48em (768px) === = == ===== /

@media only screen and (min-width : 48em) {

/ ===== == = === 56.25em (900px) === = == ===== /

@media only screen and (min-width : 56.25em) {

/ ===== == = === 68.75em (1100px) === = == ===== /

@media only screen and (min-width : 68.75em) {

/ ===== == = === 81.25em (1300px) === = == ===== /

@media only screen and (min-width : 81.25em) {
Em, How many? I lied, it’s not really basic it’s slightly more than that. Once I’ve designed (well, coded) with some or all of these breakpoints I then start getting my resizing thing down. For me that’s the key bit. Not where or when you include your media query ‘breakpoints’ in earnest, but what goes in between.  “Start with the small screen first, then expand until it looks like shit. Time to insert a breakpoint!” Although I don’t follow Stephen Hay’s words to the letter, the next part along my design(coding?) process is to resize the browser until it ‘looks like shit’ then I’ll add a breakpoint to fix it. I may even add a min-width and a max-width rule, or a max-width rule. Whatever works to make the design look nice at any viewport size, as best I can. Don’t forget to test on as many devices as possible either. You’ll also not I’m using ems for my breakpoints instead of px. This helps for users who zoom and ties your media queries more to the design than device viewport. But, what about the future? How long in the future are we going? Well as phones are being released (well, Android OS’d ones) faster than you can say Jack Robinson so are list of possible viewport sizes we’re going to have to deal with but there are still going to be more popular devices that’ll (I’m in) know doubt will keep to roughly the same pixel screen resolutions they do at the moment, if not a few years to come (in the future).  Content first? Well, content blocks first. My expectations of a client to deliver everything I need before I start are unfortunately not going to be delivered soon. The project I was working on January - March (sshhhh, we’re still working on it) this year had content that would have been provided by it’s users so I had to work with what the content could be expected to look like and where it would go etc. This worked, it worked just fine. I’d love every word to be presented, that’s not going to happen, nor should it. The web is a breathing beast, so is it’s content. My Point. I don’t think that having a set of ‘common’ media queries harms your desiging of a site as long as you resize that bad boy and fix anything that looks shit. Like all things I do when I’m coding though, this idea is subject to change.
 / * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * / var disqus_shortname = 'alwaystwisted'; // required: replace example with your forum shortname / * * DON'T EDIT BELOW THIS LINE * * */ (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = 'http://' + disqusshortname + ''; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })();
Please enable JavaScript to view the <a href="">comments powered by Disqus.</a>
<a class="dsq-brlink" href="">blog comments powered by Disqus</a>

# Wednesday, September 18th, 2013 at 12:22pm

Previously on this day

9 years ago I wrote Voice of the bot-hive

I for one welcome our new voice-activated algorithmic overlords.

12 years ago I wrote Open Data and Accessibility

I delivered the keynote presentation at the Accessibility 2.0 conference.