Welcome to the Treehouse Community
The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.
Robert Ungar15,723 Points
So what do you actually use for breakpoints?
I sort of get what Nick is trying to say here, but I don't feel like he's answering the question. OK, sure, it's a pain to have to update your code when a new device comes out but at a certain point, you have to make a selection for a breakpoint, no?
When you're letting the content determine your breakpoints, rather than the device, that doesn't really help. You still need to insert an actual width, so what are you supposed to use then? Maybe someone can explain this better than the video.
Ken AlgerTreehouse Teacher
Nick Pettit & Guil Hernandez are masters of CSS breakpoints and responsive design. Breakpoints can indeed be confusing, but let me attempt to explain what I believe the course content is trying to get across.
Yes, you need to put in hard numbers for breakpoints, there are common "recommended" major breakpoints available, one common approach is:
320 pixels - For small screen devices, like phones, held in portrait mode.
480 pixels - For small screen devices, like phones, held in landscape mode.
600 pixels - Smaller tablets, like the Amazon Kindle (600×800) and Barnes & Noble Nook (600×1024), held in portrait mode.
768 pixels - Ten-inch tablets like the iPad (768×1024) held in portrait mode.
1024 pixels - Tablets like the iPad (1024×768) held in landscape mode, as well as certain laptop, netbook, and desktop displays.
1200 pixels - For widescreen displays, primarily laptop and desktop browsers.
However, as you can already surmise, there are a lot more options out there in today's market. My understanding of what the course is trying to get across is that based on the content of your site, you design your breakpoints around that. If, for example, you are making a weather site. For small screens you provide information X and then build up. When your design starts to deteriorate as the screen size increases bingo, there's a breakpoint. Then adjust the content (larger font or images, no more hamburger menus, add images instead of text, etc.). When you have increased the screen size again, say from tablet to desktop, the design normally deteriorates again, so you create another breakpoint and adjust the content again.
Summing it up: it's your content and your design that defines the breakpoint, not the width of the most popular device in a particular moment in time.
Does that make any sense? If not please post back with further questions.
When responsive first came about people were basically relying on Apple product breakpoints, so early on it was not at all uncommon to see media queries at 320px, 768px, and so on because these covered iPhone and iPad. However, after responsive started gaining traction and becoming more of the norm, people realized that content should dictate breakpoints, not devices. All this really boils down to is, when developing, test your site and add breakpoints when you see that the content/design is not working well at the particular breakpoint. Moving away from device specific breakpoints and instead using content driven breakpoints also makes your site more future proof because as more devices come out you haven't setup breakpoints that only cater to certain devices, you have setup breakpoints that are specific to your content.
Going back to testing, I understand that not everyone has access to a plethora of different devices, but in my opinion some testing is better than no testing. You can start by simply dragging the corner of your browser to resize the site slowly and see where things start to break down.
I use the fitWeird window monitor bookmarklet quite often to see screen width as the content breaks down: http://davatron5000.github.io/fitWeird/
Amber Cookman12,405 Points
What I use to determine my breakpoints in a site design is start with the mobile-first approach, with my browser sized as narrow as it will go. Once it looks good at that size, I make sure I have my Developer Tools open (I typically work in Chrome initially), and then re-size the page larger until I see a breakpoint happen - meaning, a point where any one of many things is happening, from the content flow seeming off, to fonts clearly being an inappropriate size, to overflows, or needing to float elements left or right.
With my Developer Tools open, it shows me in the upper-right corner of my browser window the exact pixel point at which that break has occurred, then I go into my CSS and fix the breaks in my design inside a media query. This process continues until I have taken my browser to full-screen. If you use relative-sizing (percentages, ems, rems) the whole way through your CSS, you really won't have to do much tweaking.
I prefer this method because you never know what size the newest devices will be, and this makes for much more maintainable code when reaching for the goal of being easily seen on as many devices as possible. While using a pre-set list of breakpoints certainly is an option, it can make for an odd user experience on a device that sits narrowly outside of a media query, yet has the same bug in design that is adjusted for just 10px or so up/down in width.
To quote from the Brad Frost article in the teachers notes:
"The Web is inherently fluid, so it’s our job to create interfaces that look and function beautifully on any screen instead of in just a few arbitrary buckets. -- Brad Frost"
Brad Frost also quoted Stephen Hay in the same article:
"Start with the small screen first, then expand until it looks like shit. Time for a breakpoint!" --Stephen Hay (pardon the bad word, but I didn't say or write it) :)
Robert Ungar15,723 Points
Thank you for your thoughtful replies. I'm not trying to be obtuse, but I'm still not totally getting it. I understand what you and Nick are saying, in that you should ask, "How does my content look and where does it break down?," but aren't those essentially based on how they look on different categories of devices? What is it that determines that the content "breaks down?"
After you make the browser size a little bit bigger, what looks good on a phone-sized screen doesn't look good on a tablet. What looks good on a tablet doesn't look as good on a laptop when it's a little bigger. When it's a little bigger than that, it doesn't look as good on a desktop monitor.
So there has to be some standard to base that on, doesn't there?
You are getting too hung up on the concept of devices, try to put the devices out of your mind. Also, there is no metric for every site as far as when content breaks down, that is entirely dependent on the design and also personal preference for how you see things changing at that particular breakpoint. The goal here is to start mobile first and work your way outward and add media queries as the content/design calls for it. There is no one right way to do it, and some designs may require more breakpoints than others, that is why it is best to let content dictate it and not get stuck into any one pattern as it relates to specific devices.
Artem Syromiatnikov4,706 Points
I find it unclear why are pixel values used to defined the break points. My phone has 4.7" screen, my desktop monitor size is 24" - and they both share the same Full HD resolution (1920x1080). Obviously I want to see different layout for these two devices, but they correspond to the same "the largest" media query. Are there different ways to define breakpoints?
Robert, you can add a new media query for every type of device if you wish. Just find a list somewhere on Google that shows the screen sizes for every type of device. Obviously this is going to take a very long to implement though.