While it may be helpful to think about defining breakpoints based on device classes, use caution. Defining breakpoints based on specific devices, products, brand names, or operating systems that are in use today will result in a maintenance nightmare. Instead, the content itself should determine how the layout adjusts to its container.
TL;DR
Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary. This will allow you to optimize breakpoints based on content and maintain the fewest number of breakpoints possible.
Let’s work through the example we saw at the beginning, the weather forecast. The first step is to make the forecast look good on a small screen.
Next, resize the browser until there is too much white space between the elements and the forecast simply doesn’t look as good. The decision is somewhat subjective, but above 600px is certainly too wide.
To insert a breakpoint at 600px, create two new stylesheets, one to use when the browser is 600px and below, and one for when it is wider than 600px.
<link rel="stylesheet" href="weather.css">
<link rel="stylesheet" media="(max-width:600px)" href="weather-2-small.css">
<link rel="stylesheet" media="(min-width:601px)" href="weather-2-large.css">
View full sample
Finally, refactor the CSS. In this example, we’ve placed the common styles such as fonts, icons, basic positioning, colors in
weather.css
. Specific layouts for the small screen are then placed in
weather-small.css
and large screen styles are placed in
weather-large.css
.
In addition to choosing major breakpoints when layout changes significantly, it is also helpful to adjust for minor changes. For example between major breakpoints, it may be helpful to adjust the margins or padding on an element, or increase the font size to make it feel more natural in the layout.
Let’s start by optimizing the small screen layout. In this case, let’s boost the font when the viewport width is greater than 360px. Second, when there is enough space, we can separate the high and low temperature so they’re on the same line, instead of on top of each other. And let’s also make the weather icons a bit larger.
@media (min-width: 360px) {
body {
font-size: 1.0em;
}
}
@media (min-width: 500px) {
.seven-day-fc .temp-low,
.seven-day-fc .temp-high {
display: inline-block;
width: 45%;
}
.seven-day-fc .seven-day-temp {
margin-left: 5%;
}
.seven-day-fc .icon {
width: 64px;
height: 64px;
}
}
View full sample
Similarly, for the large screens, it’s best to limit to maximum width of the forecast panel so it doesn’t consume the whole screen width.
@media (min-width: 700px) {
.weather-forecast {
width: 700px;
}
}
View full sample
Classic readability theory suggests that an ideal column should contain 70 to 80 characters per line (about 8 to 10 words in English), thus each time the width of a text block grows past about 10 words, a breakpoint should be considered.
Let’s take a deeper look at the above blog post example. On smaller screens, the Roboto font at 1em works perfectly giving 10 words per line, but larger screens will require a breakpoint. In this case, if the browser width is greater than 575px, the ideal content width is 550px.
@media (min-width: 575px) {
article {
width: 550px;
margin-left: auto;
margin-right: auto;
}
}
View full sample
Be careful when choosing what content to hide or show depending on screen size. Don’t simply hide content just because you can’t fit it on screen. Screen size is not a definitive indication of what a user may want. For example, eliminating the pollen count from the weather forecast could be a serious issue for spring time allergy sufferers who need the information to determine if they can go outside or not.
Updated on 2014-04-30
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our Site Policies .