Ahh, the wonderful world of responsive design. “Responsiveness” isn’t just a buzzword bandied about by marketing execs and MBAs; it’s a necessity in today’s website world. To truly attract customers and users (or even just to avoid ticking them off), your site needs to be easily viewable from a variety of devices.
Luckily, websites that perform equally well on a widescreen monitor, tablet and mobile phone are possible with a little extra attention to detail. Meet the @media query, your new best friend (for the purposes of this article, anyway).
Back to basics: @media and breakpoints
Within the CSS for a website, we can use @media queries to control how certain content responds (see what I did there?) at different screen sizes. For example, we can have some blocks of content that display next to each other in row on a desktop monitor, but that stack vertically on a mobile phone for easier viewing.
The most used method is to define certain breakpoints for content. These breakpoints can be anything, but usually correspond to common screen sizes for different types of devices. The behavior of our elements remains the same until one of these points is reached, then gets redefined or adjusted. Assume our CSS file contains this code:
#content .main-container { max-width: 1000px; }We can add a media query to change the overall allowed width of our content area only when below a certain screen size:
@media only screen and (max-width: 800px) {
#content .main-container {
max-width: 600px;
}
/* possibly more css code here... */
}In this example, the main container for our content would not exceed 600px for any screen size smaller than 800px total. At anything over 800px, the container would retain its original 1000px max value.
You can also set queries with both a minimum and maximum value:
@media only screen and ( min-width: 761px ) and ( max-width: 1024px ) {
/* some css code here... */
}You can also change the media types. The above examples affect only screens; there are other media types that allow you to set definitions for different cases, like printing the page or viewing specifically on handheld devices.
You can see how these queries could be incredibly helpful or get overly complicated rather quickly. Here are some tips to help you better navigate the rapids of responsive coding.
The Good, The Bad, and The Ugly
Pick your battles
The beauty of @media queries is they allow you to adjust or change the elements of your site at as many viewing sizes as you’d like. The problem with @media queries is they allow you to adjust or change the elements of your site at as many viewing sizes as you’d like. It can be easy to get caught up in defining elements at so many points that the CSS becomes a maintenance nightmare. You can’t please everyone, and you might NOT be able to optimize your 1600px width design to look good on a 200px screen. But you can at least try to hit the big three: screen, tablet and mobile.
The Good: start with just a few logical breakpoints. Take a look at some of the most common device sizes and start with breakpoints at those places. You can always add more later if you need them.
The Bad: set a breakpoint for every conceivable size for every device in existence. Obviously, this is a bad idea. It would be confusing, a LOT of work, and complete overkill, since setting just a few major breakpoints will usually suffice.
The Ugly: set only one or two breakpoints. Or, you know, don’t bother setting any at all. People can just pan and slide the screen around to see it all.
Read ‘em (but don’t weep)
It is possible to find a font that looks good on a variety of devices; in fact, most web-safe fonts pass this test. But a font size that works on a widescreen desktop monitor might not work when viewed on a tablet. Try to keep various potential device sizes in mind when you design a website and choose your font types and sizes appropriately.
The Good: define fonts using a relative size. We won’t go into all of the different font units here, but basically, using a percentage (%) or em size to define your fonts allows them to be easily scalable to other devices.
The Bad: define fonts using a set size. Setting a font to be “16px” or “14pts” means that text remains that size, no matter what the size of your screen.
The Ugly: defining font sizes at every breakpoint. The font sizes are initially defined as set sizes, but then are re-sized at each screen size change. This is possible, but it makes for convoluted, confusing and overly complicated CSS code.
A picture is worth 1,000 pixels
Just like your fonts, try to avoid setting images in such a way that they don’t scale on smaller devices. That picture of a windsurfing wombat on your home page mightlook really cool, but it’s not nearly as impressive when all you see on a mobile phone are six blue pixels and a corner of a cloud. And remember, it’s OK to reduce the number of images at smaller resolutions.
The Good: define images that can scale, and choose when (at what breakpoint/s/) to hide them altogether or replace them with icons.
The Bad: leaving too many images on a smaller size setting, and causing the flow of the site to be choppy because there are too many pictures to easily fit (even if they are small pictures).
The Ugly: don’t bother making adjustments. Just leave the images big and make sure there are a bunch of them. That’s what mobile data plans are for, right?
A note about emulators
One final piece of advice about responsive coding: nothing beats the original. There are a number of emulators available online to simulate what your website will look like on various devices. While some of them might prove helpful, many will not accurately “translate” your changes. Want to know what your site looks like on a mobile phone? Pick up your phone and check it out. Need to see the design on a tablet? Grab a tablet.
What other tricks do you use to navigate the rapids of responsive design? Share your knowledge in the comments.
