Common breakpoints for media queries on a responsive site

So I am working on my first responsive website which makes extensive use of media queries. I was wondering if there are some common page-widths I should optimize for.

I will probably have a maximum width (not going full fluid) I am thinking I'll have maybe 3-5 set widths with fun little CSS3 transitions between them (similar to how CSS Tricks works).

Currently the numbers I am using are somewhat arbitrary:

@media all and (max-width: 599px){...}
@media all and (min-width: 600px) and (max-width:799px){...}
@media all and (min-width: 800px) and (max-width:1024px){...}
@media all and (min-width: 700px) and (max-width: 1024px){...}
@media all and (min-width: 1025px) and (max-width: 1399px){...}
@media all and (min-width: 1400px){...}

Also, I think I have read that some mobile devices don't behave as expected (with @media). Where does this come into play and how should I deal with these situations?


  • This is a pretty useful guide for mobile screen sizes.
  • Great guide for stats on screen resolutions
  • Google Analytics data on resolutions can be valuable as well, if you have access to it.

Also, I would definitely recommend using device-width for your mobile sizes, unless you want users to see your mobile styles when they resize their browser window on a non-mobile device. width is the width of the viewport, and device-width is the current resolution of the device.

Also, I think I have read that some mobile devices don't behave as expected (with @media).

You are correct. Many devices will not give you the width or device-width that you expect, especially when switching between landscape and portrait (they will often give the landscape width when in portrait). Device auto-zooming can also throw a wrench into things. Using the viewport meta tag can help with many of these issues. (More info on that here)


When deciding on breakpoints for your media queries, consider these realities:

  • There are hundreds of different screen sizes across thousands of different devices.
  • The future will bring new screen sizes.
  • Apple, Samsung, Microsoft, LG, Nokia and any other device manufacturer can, at any time, change the screen size of their popular models.

With so many viewport possibilities, matching breakpoints to specific devices doesn't sound like an efficient strategy. Just keeping up with what's popular, what's new, and what's changed will be a never-ending task.

A better approach may be to set breakpoints based on content and layout.

With this approach your site uses its natural breakpoints to adapt to all viewport sizes, rather than artificial breakpoints targeting currently common screen sizes.

This method is so simple and easy it may be hard to believe:

  1. Run your website on a desktop or laptop.
  2. As you narrow the browser window, notice how the website responds.
  3. When you reach the point where your layout is no longer perfect, that's your first breakpoint.
  4. Adjust your site for that screen size (which may have no relation to any device).
  5. Keep narrowing the browser window.
  6. When you hit the next layout problem, that's your second breakpoint.
  7. ... and so on and so forth.

Of course, if you're designing mobile-first, then the process goes in reverse: Start with a narrow screen and work your way out.

With natural breakpoints you no longer need to focus on a giant universe of viewport sizes because your site will adapt to any device, both now and in the future.


According to one developer, this approach brings breakpoints full-circle to their original intent:

I'm not sure how we ever came up with the phrase "device-specific breakpoints" anyhow... As I've understood it, the term "breakpoint" was always a reference to where the content or layout would "break" (i.e. appear flawed) and thus you'd need to apply a media query at that point. But I guess that's just semantics, I just always thought it was common sense to refer to breakpoints in the context of content or layout.

~ Louis Lazaris, ImpressiveWebs

source: https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints#comment-1685967450


More information (external sites):

  • Why You Don't Need Device Specific Breakpoints
  • Setting Breakpoints in Responsive Design
  • Google Developers: How to choose breakpoints
  • The Goldilocks Approach to Responsive Design
  • Viewport Sizes (a list of hundreds of devices and viewport sizes)
  • Media Queries for Standard Devices (a list of media queries targeting popular devices)

This is what I use...

@media screen and (max-width:320px) {}
@media screen and (min-width:321px) and (max-width:639px) {}
@media screen and (min-width:640px) and (max-width:959px) {}
@media screen and (min-width:960px) and (max-width:1279px) {}
@media screen and (min-width:1280px) and (max-width:1599px) {}
@media screen and (min-width:1600px) {}
@media screen and (min-width:1920px) {}
@media print {}

There are all kinds of others in there, as appropriate (min-width without max-width or max-width without min-width), but this is my base setup.

Personally, I never understood the odd widths that a lot of people use. For instance, 320 and up has Five CSS3 Media Query increments: 480, 600, 768, 992 and 1382px.

That doesn't make any sense to me. Logical breaks are at intervals of 320px (320, 640, 960, 1280, 1600, 1920). Note that these breaks can give a slightly different layout for pretty much any device in either orientation (omnia is 240x400, iphone is 320x480, droid x is 480x858, ipad is 768x1024, galaxy s3 is 720x1280, and they are talking 1920x1080 tablets).

JJ


some resolutions to look for:

iphone screen (a lot of other smartphones have similar screen sizes: 960-by-640-pixel resolution at 326 ppi http://www.apple.com/iphone/specs.html

ipad screen (a lot of other tablets have similar screen sizes 1024-by-768-pixel resolution at 132 pixels per inch (ppi) http://www.apple.com/ipad/specs/

'normal' screen a lot of normal screens also have a 1024-by-768-pixels resolution, according to: http://www.w3schools.com/browsers/browsers_display.asp but I'm not vouching for their trustworthyness.

I'm looking for more data now.