Stop using device breakpoints
Tags: responsivedesign, webdev, css, design
Published: 2017-09-23 21:59:05

---
title: "Stop using device breakpoints"
published: true
tags: Responsive Design,Web Development,CSS,Design
canonical_url: https://medium.com/simple-human/stop-using-device-breakpoints-b11a87e2625c
cover_image: https://cdn-images-1.medium.com/max/2000/1*vHm-dfkzQy_tzdeDZwHesA.png
---

I see it all the time. Designers, and developers alike, setting breakpoints according to their favourite device. When will we learn from our past mistakes?

When the web came along we settled on 640 pixel widths. Then a few years later, when larger monitors came to market, we settled on 960 pixels. We no longer cared about people with smaller monitors.

Then more years passed. The mobile web was born. Or more accurately, we could consume websites on our phones, which happen to have small screens. A million browsers came out. A million devices came out. And browsers gave us media queries.

At about this time, we decided to use 320 pixels for mobile. _Why?_ Because a lot of us had the iPhone, and this was its width in portrait.

 ![](https://cdn-images-1.medium.com/max/2000/1*PO-X9g5ZJZQFDILcbAaDdA.png)
<figcaption>And then. And then. AndÂ then.</figcaption>

Then landscape mode. Then tablet (that’s still mobile right?). Then desktop. Then big desktop like super size thunder screens or whatever the hell they’re called. (I’m not Googling it because you know what I mean). Then TV. Then wristwatch and then...

You get the point. The web is not print. The web is the web and we have no idea what size screen our users have. We just can’t control that. And even if we could, the proliferation of devices means that designing for them is futile.

But there’s a few things we _do_ know. We know our brand and our UI. And, more importantly, we know our _content_. Content isn’t just paragraphs of text. It’s _the things that are held or included in something._

We should always start with content. Without content, design is meaningless. We _design_ to help users consume _content_. We don’t use content to help users enjoy our designs.

We often start designing with a box. And then we put smaller boxes inside it. Then later we’ll fill in these boxes with actual content.

As Frank Chimero beautifully explains in [The Web’s Grain](http://www.frankchimero.com/writing/the-webs-grain/), _this is just about the worst thing we can do_.

How can we possibly design something until we know what the content is?

I’ve witnessed designers finish their mock-ups and ask the resident content designer to make the content fit. Maybe even ask them to shorten their user-friendly content to make sure it doesn’t wrap and so forth. It may help the designer. It doesn’t help the user.

And when they check their design on landscape or on a device they don’t own, they get flustered. What they see as control, is really an unnecessary constraint on their design to a known set of device sizes.

Instead we should let content be our guide. We should set a breakpoint when and _if_ the content requires it. We can call them _content breakpoints_ or what Frank refers to as _points of reassembly_.

Take for example the subscribe form on [MaintainableCSS](http://maintainablecss.com). Taking a content-led, small-screen first approach, the button sits under the text box. And when there’s room, they sit along side each other.

 ![](https://cdn-images-1.medium.com/max/800/1*BqGlYQLXhhRp7buZYx1ejw.png)
<figcaption>Responsive subscribe form based on content breakÂ points</figcaption>

The media query uses a breakpoint of `36em`. _Why?_ Because that’s when there is an opportunity for content reassembly. The button and text control lose their affordance when they get really wide on bigger screens. So we can fix that.

And it’s only relevant to the subscribe form. There is no blanket rule that states that `36em` means “big”. The breakpoint reflects the need of the module and content in question.

_Technically_ it’s just a media query. But the mindset and the approach is what sets it apart. The design supports the content. Not the other way around.

This is why CSS [frameworks](http://getbootstrap.com/css/) cause problems by unnecessarily constraining our content to fit into a predefined grid. How can a CSS framework know what our content is? It can’t.

The term _mobile first_ encourages us to think in terms of device. But the web isn’t a set of devices. The web is a continuum of edgelessness. That’s the coolest sentence I’ve ever written.

Sorry for using jargon. What it means is this. There is absolutely no pointâ€Š–â€Šwhatsoeverâ€Š–â€Šin trying to work out the size of a particular device, in order to then define a codified responsive grid.

At best it’s constraining and at its worst, it causes problems.

Instead, let the content be your guide. If and when it breaks we can reassemble it with the necessary content breakpoint.

Responsive design frees us from the shackles of designing based on devices, which is impossible to get a handle on. Content breakpoints give people better experiences no matter what size device they have.

**_That’s the end. But, if you liked this article, you should_** [**_subscribe to my private mailing list_**](http://adamsilver.io/signup) **_. I send an article like this about once a month straight to your inbox. It’s a good way to continue the conversation._**



_This post was originally published on [medium.com](https://medium.com/simple-human/stop-using-device-breakpoints-b11a87e2625c)_