In an age of responsive design, breakpoints are key to a successful site; it's all about defining where our design might break, if we were to resize the available screen width. It is important to understand that no two sites will have identical queries in use; this said, there are some we can use that can be used as a basis for our designs.
We'll start with this one, for standard desktops:
@media only screen and (max-width: 768px){
/* CSS Styles */
}
With the meteoric rise in mobiles, we can't forget those who are fortunate enough to own a smartphone, such as an iPhone:
@media only screen and (min-device-width: 320px) and (max-device-width: 480px) {
/* Styles */
}
The downside of this query means that it would equally apply to any device that was small enough to satisfy the *-device-width dimensions given. This is not what we want (or intended); to set a cleaner division between mobile devices and desktops, we can adapt the query thus:
@media only screen and (max-device-width: 320px) {
/* Styles - for mobiles in portrait mode */
}
This one is for mobiles in landscape mode:
@media only screen and (min-device-width: 321px) {
/* Styles - for mobiles in landscape mode */
}
Taking it even further, we can also cater for tablets, such as iPads:
@media only screen and (min-device-width: 768px) and (max-device-width: 1024px) {
/* Styles */
}
A similar caveat applies here though – we've not set a sufficiently clear threshold that can only apply to tablets. We can fix that, by adding the orientation attribute:
@media only screen and (min-device-width: 768px) and (max-device-width : 1024px) and (orientation : portrait) {
/* Styles */
}
To complete the picture, we can equally apply a check for when tablet content is being displayed in landscape mode:
@media only screen and (min-device-width: 768px) and (max-device-width : 1024px) and (orientation : landscape) {
/* Styles */
}
These breakpoints are just a small selection of what could be used to add media queries to any site; this does not mean we should use them blindly; we should only add those queries that allow us to support our target devices. We can of course add custom queries, although there is a risk that we can add more than is necessary. Let's take a moment to consider the implications of adding custom queries, and why this can become an issue for our projects.
The media queries we've already outlined should cover a wide range of scenarios; there will be occasions when these won't suffice, and our site isn't working as expected.
What do we do? Well, we are not limited to using the standard queries we've already covered; we can absolutely create our own!
Creating a custom breakpoint is very easy, as long as we do it the right way; done incorrectly, and we can create unnecessary breaks that have a limited use or an unintended knock-on effect to other devices. To see what we mean, let's work through a (theoretical) example.
Imagine your site has been resized to around 335px, and we see it is a little out of kilter—there are a number of elements that don't quite fit properly. To better manage content at this breakpoint, the temptation would be to write a query such as this:
@media only screen and (max-device-width: 345px){
/* Styles */
}
We would add our changes in the area headed by /*Styles*/.
Sounds reasonable, right? It would be, if it weren't for one thing: we've now just created a whole new set of problems for viewing devices that have a width lower than 345px!
The key to solving this issue is to not simply use a bigger pixel value, as this may break the layout for other devices—this includes mobile devices, in portrait or landscape modes. The right way to fix this is to identify the exact circumstances where our query fails, and to either adjust the query to better match the circumstances or (ideally) work out if the design itself can be tweaked to avoid the need for a query.
So, for example, if our site broke between 325px and 345px, and that the failure was in portrait mode only, we would create a media query such as this one:
@media only screen and (min-device-width : 325px) and (max-device-width : 345px) and (orientation : portrait) {
/* Styles */
}
How does this help us? Well, refining our query to be more explicit avoids any possible conflict with more generic queries that we might have already created. We're also making the threshold limits clearer too; we won't trigger the query unless we can match all three conditions at the same time.
Some developers may ask why we simply don't just fix the available viewport; this changes size when we change orientation, so surely the content will adjust to fit, right?
Well, yes and no. It's all about understanding where content is positioned, and the types of devices we want to support, in addition to desktops. We should not forget that it is perfectly valid to have a layout that is different in portrait mode to those in landscape; try looking at Packt's site in landscape and portrait modes on an iPad!
At the time of writing, an extra element is displayed in portrait mode, but it is not present in landscape orientation. If one of the elements in the portrait mode was broken and not displaying correctly, then simply specifying numerical breakpoints will not work. To fix the issue, we must also specify the affected orientation, otherwise fixing one mode may break another.
Okay, so we've created a bunch of media queries, ready for implementing into a site. We're good to move on and start building some examples, or are we? If I said to hold fire for a moment, you would very likely think I've lost my marbles; but as always, there is a good reason. Let me explain.
A drawback when using media queries is that no two sites will be the same; this means that we can't always reuse standard queries in multiple sites. There will be times when we have to create custom breakpoints to satisfy a requirement for a site; the trick is to know when and where our site may need extra attention, over and above the normal breakpoints we might have used in our site.
Creating custom, ad hoc queries is easy, but we do run the risk of creating too many, which undermines the whole concept of responsive design. Can we get around this? Well, yes we can; it involves a shift in our approach to designing, which is not to focus on viewport sizes, but our content instead.
Up until now, we've covered how we can use breakpoints to control what is displayed, and when, according to which device is being used. Let's assume you're working on a project for a client and have created a series of queries that use values such as 320px, 480px, 768px, and 1024px to cover support for a good range of devices.
No matter what our design looks like, we will always be faced with two issues if we focus on using specific screen viewports as the basis for controlling our designs:
- Keeping up with the sheer number of devices that are available
- The inflexibility of limiting our screen width
So, hold on. We've created breakpoints, yet this can end up causing us more problems? If we're finding ourselves creating lots of media queries that address specific problems (in addition to standard ones), then we will start to lose the benefits of a responsive site; instead we should re-examine our site to understand why the design isn't working and see if we can't tweak it so as to remove the need for the custom query.
Ultimately, our site and target devices will dictate what is required—a good rule of thumb is if we are creating more custom queries than a standard bunch of four to six breakpoints, then perhaps it is time to recheck our design!
As an alternative to working with specific screen sizes, there is a different approach we can take, which is to follow the principle of adaptive design and not responsive design. Instead of simply specifying a number of fixed screen sizes (such as for the iPhone 6 Plus or a Samsung Galaxy unit), we build our designs around the point at which the design begins to fail.
Why? The answer is simple. The idea here is to come up with different bands, where designs will work between a lower and upper value, instead of simply specifying a query that checks for fixed screen sizes that are lower or above certain values. Don't worry for now if it doesn't entirely make sense just yet; for now, the key here is that we're creating designs that mean we can reduce the need to support so many devices.
Let's put this theory into practice, and start creating some demos to show off how we can use media queries in practice.