When I first started messing around with responsive web design (RWD) and CSS media queries, I often found myself researching the heights and widths of specific devices so that I would know where to set my breakpoints. Once I became more comfortable with RWD, I realized that this process was undoubtedly inefficient due to one main reason: new devices of different sizes are constantly emerging.
It was very time-consuming (and a huge headache) to account for each specific device that users could be viewing the content from. Eventually, I came to the conclusion that I could simplify my process by only creating breakpoints when they were needed. By doing this, I was able to account for all devices, while minimizing the weight of my stylesheets.
How do I know when to set a breakpoint?
When testing responsiveness in a browser, as you expand or contract the window, you will begin to notice points at which your layout has been compromised or “broken.” These are great places to put breakpoints, but what constitutes a layout as broken?
There can be many indicators that your layout is broken, and much of it is the personal preference of the web designer, developer, or even the client. Textual content plays a major role in my decision to add breakpoints. It is always a good idea to make sure that the content readability is optimized for your users. Is the text too big or too small? Are there too many words per line? What about the line height? All of these things should be considered to provide the best user experience.
Many of the other “broken layout” indicators will be pretty obvious when looking at your browser window. For instance, when a set-width element is flowing outside the width of the viewport (or even a containing element) you may consider a breakpoint at which you would change a set pixel width to a percentage width. The screenshot below shows a header area with a set width. The navigation and search bar that are contained within are getting cut off when the viewport shrinks to a certain width.
Setting breakpoints based on the content rather than the device size will ensure that you’ve covered any devices currently on the market, as well as those that will be released in the future. These considerations can save you a ton of time and hassle down the road when it is time to make updates.