The use of mobile devices to surf the web is growing at an astronomical pace, but unfortunately much of the web isn't optimized for those mobile devices. Mobile devices are often constrained by display size and require a different approach to how content is laid out on screen.
There is a multitude of different screen sizes across phones, “phablets”, tablets, desktops, game consoles, TVs, even wearables. Screen sizes will always be changing, so it’s important that your site can adapt to any screen size, today or in the future.
Responsive web design, originally defined by Ethan Marcotte in A List Apart responds to the needs of the users and the devices they’re using. The layout changes based on the size and capabilities of the device. For example, on a phone, users would see content shown in a single column view; a tablet might show the same content in two columns.
Almost every new client these days wants a mobile version of their website. It’s practically essential after all: one design for the BlackBerry, another for the iPhone, the iPad, netbook, Kindle — and all screen resolutions must be compatible, too. In the next five years, we’ll likely need to design for a number of additional inventions. When will the madness stop? It won’t, of course.
In the field of Web design and development, we’re quickly getting to the point of being unable to keep up with the endless new resolutions and devices. For many websites, creating a website version for each resolution and new device would be impossible, or at least impractical. Should we just suffer the consequences of losing visitors from one device, for the benefit of gaining visitors from another? Or is there another option?
Responsive Web design is the approach that suggests that design and development should respond to the user’s behavior and environment based on screen size, platform and orientation. The practice consists of a mix of flexible grids and layouts, images and an intelligent use of CSS media queries. As the user switches from their laptop to iPad, the website should automatically switch to accommodate for resolution, image size and scripting abilities. In other words, the website should have the technology to automatically respond to the user’s preferences. This would eliminate the need for a different design and development phase for each new gadget on the market.
For all that’s changed, it’s amazing how much has stayed the same. The basic principles of responsive web design that Ethan wrote in his article are just as relevant as ever.
As I mentioned in the introduction, responsive web design solves the problem of making the same code work across multiple screen resolutions. Many modern websites are responsive, and in fact, the Treehouse Blog is one of them. If you resize your browser window, you’ll see the screen elements resize themselves like so:
There’s a myriad of web capable devices already available, and there are new form factors every day, so it’s impossible to target each individual screen. Instead, it’s better to let the website respond to its environment and adapt fluidly.
Practically speaking, this involves three main principles that come together to form the whole that is responsive design. They are:
Let’s take a look at each one in more detail.
Traditionally, websites have been defined in terms of pixels. This is an idea that was carried over from the print industry, where a magazine or a newspaper was always going to be the same fixed size. For better or worse, this is not how websites are displayed. Rather, a website might appear in a large format like on a television, or on a very small screen like a smartphone (or even a smartwatch). For this reason, responsive websites are built with relative units like percentages, rather than fixed units like pixels.
If you’re used to designing in pixels, there’s a simple math formula that can help you transition to using percentages. It looks like this:
target / context = result
For the sake of explanation, let’s say that you have a website that has a wrapper containing the site to a width of 960 pixels, and you’re looking at this site in a maximized browser window on a screen that’s 1920 pixels wide. In this case, the width of the browser window is the context and the wrapper is the target. In order for the site to look exactly the same, you can divide the target by the context to get a percentage value.
Now, what about child elements that are nested inside the wrapper element? The same rule applies all the way down. As another example, let’s say that you have a two column layout inside of your 960px wide site. The left column is a sidebar that’s 300px wide and the right column is the main content area at 640px wide. You also want 20px of margin between the two columns. Here’s an image illustrating what that might look like:
There have been many advances in responsive images (detailed later in this post), but the core idea is that images should be able to shrink within the confines of a fluid grid. This can be done very simply with a single line of CSS code:
This will tell the browser that any images should only ever be as large as their pixel value, which will ensure that the image is never stretched or pixelated. However, if they’re nested inside a parent container that’s smaller than their pixel value, then the image should shrink. So for example, if an image with a width of 800px is placed inside a container that’s only 600px wide, the image will also shrink to be 600px wide. The height will be calculated automatically and will maintain the original aspect ratio.
If you take our original two column layout and try to shrink it down to a mobile phone, it’s a bit challenging. Typically smartphones are used in portrait mode, meaning that the screen is taller than it is wide. This lends itself to websites that scroll vertically, but it’s not good for wide layouts with several columns. That’s where media queries come in. Media queries are a CSS technology that have been available in browsers for several years now, and they’re a core component of responsive design. Media queries allow CSS to only be applied when specific conditions are met. For example, you could write a media query that will only applies CSS if the browser reaches a specific width. That means that when a design is too large or too small, a media query can be used to detect the site width and serve CSS that appropriately rearranges the site’s content. Using the previous two column layout as an example, let’s say that we want to move the sidebar up to the top on mobile screen sizes. It’s actually better to do this by creating the mobile styles first and then using the media query to apply styling for the larger size (this is called a mobile first approach, which we’ll dig into more in a moment). The media query to do that might look like this:
Additionally, here’s a modified version of the previous CodePen embed so that you can see what this looks like in context. Please note that unless you resize your browser window to a smaller screen size (or you’re on a mobile device) this will look the same as the previous example.
At a certain point, any fluid grid layout will start to “break” and no longer look good. For example, if a mobile layout that takes up 100% of the browser width were stretched to a desktop size, the space wouldn’t be very well utilized. The point at which a layout no longer looks good is called a breakpoint. Responsive sites define their breakpoints through a series of media queries. In general, responsive code might look something like this
This is just a small example. In practice, you might have many more media queries at sizes that are appropriate for your content. While I recommend using your site’s content as a guide for creating these breakpoints, screensiz.es has the best listing I’ve seen of device resolutions, just in case you need it.
Even before the start of the responsive design revolution, the idea of using a “mobile first” approach started to take hold. Mobile first is the idea of designing the smartphone experience first and then working upwards to tablets, desktops, and possibly beyond. In the now famous Mobile First post from Luke Wroblewski, there are several reasons given:
Mobile web browsers represent a rapidly growing demographic and will likely eclipse desktop browsing (if it hasn’t happened already) Small mobile screen sizes force designers to focus, because there’s no room for sidebars, ads, social media buttons, and other peripheral content Mobile devices typically have more capabilities than their desktop counterparts, such as touchscreens, GPS, accelerometer data, and more Designing a responsive site with a mobile first approach is a natural evolution of both ideas. As demonstrated in the previous example, it can be tricky to cram a multi-column layout into a smaller screen space. Instead, it’s much better to start simple, then work upwards to more complex designs. In fact, creating a mobile experience first may benefit the desktop layouts as well, because the user experience will naturally be more focused.
Front-end frameworks like Foundation and Bootstrap have been around for some time, but more recently they’ve become responsive frameworks. In other words, their grids have responsive design in mind from the start. This is a huge step forward, because most of the time you don’t need to do any fluid grid calculations at all. Rather, the responsive grids included with a modern front-end framework just works immediately.
As an example, take a look at this template from Foundation:
Unless you’re building an extremely simple 1-page website, it’s almost always a smart idea to pick a front-end framework to start out with, even if it’s just for rapid prototyping. The responsive grids in these frameworks are very robust and thoughtful, so there’s no need to “reinvent the wheel” and start over.
Beyond just multiple screen resolutions, web designers now have the added challenge of multiple pixel densities. Phones, tablets, laptops, and even some desktops, might have 2x or even 3x the number of pixels. In my own opinion, I think the best way to handle high DPI displays is to use an SVG first approach. In other words, anything that’s not a detailed photograph or illustration should be an SVG, because they can scale to any resolution and the file sizes are typically small.
If photographs or any kind of JPEG images are required (and they almost always are), typically you can get away just making them twice the size of their parent container. So for example, if the parent is 400 pixels wide, the image inside should be at least 800 pixels wide. This same trick works for background images when the property is set to 50% or less.