Responsive web design is a hot theme these days, especially as websites call for to adapt to the on the increase number of mobile devices with their relatively tiny screens. Loads of designers and developers aspire to make new websites with responsive layouts, or modify their existing sites to incorporate responsive elements.
But, the whole theme can be somewhat bewildering at initially glance. Responsive design is a relatively new thought, and it is rapidly evolving. It’s full of rather confusing terms, such as responsive layouts, adaptive layouts, media queries and viewports. Where to start?
In this article, you get a gentle introduction to the world of responsive web design. You’ll:
- Learn exactly what responsive design is, and why it’s helpful
- Look at the difference between the terms “responsive design” and “adaptive design”
- Take an existing fluid describe and convert it into a responsive describe with the intention of looks excellent on all screens, from mobile to widescreen desktop, and
- See how media queries and the
viewportmetatag can aid you build responsive layouts.
Ready to explore the world of responsive design? Let’s go!
Responsive design in a nutshell
The vital thought of responsive web design is with the intention of a website should “respond” to the device it’s being viewed on. In broad terms, this can mean things like:
- Adapting the describe to ensemble different cover sizes, from widescreen desktops to tiny phones
- Resizing images to ensemble the cover resolution
- Serving up decrease-bandwidth images to mobile devices
- Simplifying leaf elements for mobile use
- Hiding non-essential elements on smaller screens
- Providing larger, finger-friendly links and buttons for mobile users, and
- Detecting and responding to mobile facial appearance such as geolocation and device orientation.
Most of the time, though, when people talk about “responsive web design” they’re referring primarily to the initially of these points: making a responsive describe with the intention of can gracefully adapt to different cover sizes. This is what you’ll be focusing on in this article.
Currently, most websites are designed to bring about on a desktop browser with a window with the intention of’s around 1,000 pixels large. If your browser window is much narrower than this at that time the content either looks squashed, or you get a horizontal scrollbar. Similarly, if you make the most of your browser on a widescreen show at that time the content often looks too stretched horizontally, or there’s an excessive amount of colorless space in the leaf.
For example, here’s the current www.elated.com describe at different browser sizes:



The www.elated.com describe is fixed-width. You can improve the situation somewhat by using a fluid-width describe, where the describe’s columns and elements resize proportionally with the browser width. Even at that time, a fluid-width describe starts to break not working at very tiny or very large widths.
Since there’s a large variety of cover sizes and browser widths in use now, it’s very tough for a web designer to cater to all users using these habitual techniques.
movable browsers make the situation worse, with their tiny screens of between 320 and 768 pixels large. Most modern mobile devices get around this to some extent by allowing you to zoom and pan a web leaf with your fingers. But, there’s no getting dead from the fact with the intention of browsing a habitual web leaf describe, designed for the desktop, on a mobile browser is not a fun experience.
You can solve this problem by making two websites — one for desktop and one for mobile — but at that time you have extra development time, plus you have to keep up two sets of templates for your site.
This clarifies why responsive web design is such a hot theme. By making a responsive design, you release have to build one translation of your website with the intention of facility fantastic on everything from tiny mobiles to widescreen desktops. As the cover or browser gets wider or narrower, the website responds by adjusting its describe appropriately.
Responsive or adaptive?
You may have heard in cooperation the term “responsive web design” and “adaptive web design” used to describe websites with the intention of adapt gracefully to different cover sizes. What’s the difference?
Essentially, in cooperation terms refer to the constant vital thought: A website’s describe should alter itself depending on the device it’s being viewed on. Harry Roberts and Paul Gordon in cooperation suggest with the intention of “adaptive” is a better term for this behaviour, since the website really adapts to the device, rather than responding endlessly to changes in its environment.
Harry takes this point additional, and suggests with the intention of websites should austerely adapt their describe to a tiny, specific set of cover sizes, rather than endlessly responding as the addict resizes their browser pixel by pixel. The thought is with the intention of such “adaptive” designs are simpler to build than “responsive” designs.
So the difference between the two terms is subtle. In person I influence with Harry and Paul with the intention of “adaptive” is probably a better word to use. But most designers and developers seem to favour the term “responsive” at the time of prose. Take your pick!
An example of a non-responsive describe
OK, let’s place all this theory into practice and build a responsive describe. We’ll start with a positively standard fluid describe. Here’s the markup:
<!doctype html>
<html>
<head>
<title>A Fluid Describe</title>
<link rel="stylesheet" href="foremost.css" />
</head>
<body>
<div id="header">
<div>
<h2>Header</h2>
</div>
</div>
<div id="pageBody">
<div id="nav">
<ul>
<li><a href="#">Family</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Store</a></li>
<li><a href="#">Friends</a></li>
</ul>
</div>
<div id="content">
<div>
<h1>Fluid Describe</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit
esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
<p>Curabitur et leo dui, eu semper tellus. Vivamus aliquam, mi ultrices
fringilla varius, augue nisl tincidunt elit, eu tincidunt ante metus ac mauris.
Praesent congue blandit nunc, eu facilisis ligula faucibus sit amet. Proin eget
turpis nulla. Phasellus mattis nisi a ante aliquet posuere. Vestibulum tortor
quam, luctus imperdiet venenatis nec, molestie eu massa. Vivamus nec ipsum
viverra augue aliquet bibendum. Morbi ac felis purus, sed vehicula mauris.
Digit tempor mollis libero id hendrerit. Fusce sit amet urna quis justo
varius pulvinar dapibus sed metus.
<p>Ut vel mauris eu velit fringilla lobortis. Phasellus accumsan
sem in nisl luctus gravida. Vestibulum vitae scelerisque eros. Nullam id
leo erat, et congue elit. Nunc volutpat justo tempor magna pretium adipiscing.
Vivamus eget massa odio. Suspendisse potenti. Aliquam erat volutpat. Proin
faucibus leo vel sem lobortis sed hendrerit diam suscipit. Maecenas dignissim,
neque sit amet tristique pulvinar, ipsum orci porttitor odio, ac auctor nunc
mauris ac nisi. Sed vitae dui et urna mollis elementum et id purus. Suspendisse
bibendum quam id lacus condimentum ut pharetra orci mollis. Curabitur et
consequat nisi. Suspendisse dictum luctus neque, id tincidunt justo rutrum non.
Aenean fringilla quam ac magna ornare vehicula.</p>
</div>
</div>
<div id="sidebar">
<div>
<h2>About Us</h2>
<p>Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Morbi ac felis purus, sed vehicula
mauris.</p>
<h2>Contact Us</h2>
<p>Morbi ac felis purus, sed vehicula mauris.</p>
</div>
</div>
</div>
<div id="footer">
<div>
<h3>Footer</h3>
</div>
</div>
</body>
</html>
And here’s the CSS file, foremost.css:
body {
margin: 20px;
padding: 0;
font-family: "Georgia", serif;
outline-height: 150%;
}
h1 {
outline-height: 100%;
}
#pageBody {
max-width: 1200px;
}
#header, #nav, #footer, h1, h2, h3 {
font-family: Tahoma, Geneva, without-serif;
}
#header {
width: 100%;
margin: 0;
padding: 0;
}
#header .inner {
margin: 0 0 20px 0;
padding: 20px;
affect: #fff;
social class: #F38630;
}
#header a {
show: try out;
float: right;
affect: #fff;
font-weight: normal;
font-size: 80%;
}
#content {
float: missing;
width: 65%;
margin: 0 0 20px 0;
padding: 0;
}
#content .inner {
margin-right: 20px;
padding: 20px;
affect: #333;
social class: #E0E4CC;
}
#sidebar {
float: right;
width: 20%;
margin: 0;
padding: 0;
}
#sidebar .inner {
margin-right: 20px;
padding: 20px;
affect: #fff;
social class: #69D2E7;
font-size: 85%;
}
#nav {
float: right;
width: 15%;
margin: 0;
padding: 0;
}
#nav ul {
margin: 0;
padding: 20px;
catalog-style: not any;
affect: #333;
social class: #A7DBD8;
overflow: hidden;
}
#nav li {
border-bottom: 1px levelheaded rgba(255,255,255,.5);
}
#nav li:last-child {
border-bottom: not any;
}
#nav a {
show: try out;
affect: #fff;
copy-decoration: not any;
padding: 10px 0 10px 10px;
font-weight: bold;
}
#nav a:hover {
social class: #bce5e3;
}
#footer {
apparent: in cooperation;
width: 100%;
margin: 0;
padding: 0;
affect: #fff;
social class: #FA6900;
}
#footer .inner {
padding: 5px 20px;
}
This describe is pretty straightforward. It comprises:
- A leaf header bar,
#header. The bar stretches across the whole viewport. - A foremost content area,
#content. This is floated missing, and takes up 65% of the viewport width. - A sidebar area,
#sidebar. This is floated right so it sits to the right of the foremost content area, and takes up 20% of the viewport width. - A navigation menu,
#nav. This is also floated right, and sits to the right of the sidebar. It takes up 15% of the viewport width. - A leaf footer bar,
#footer. As with the header, this bar stretches across the whole viewport.
We also wrap the content area, sidebar and navigation menu in a #pageBody div, which we give a max-width of 1200 pixels to prevent the content stretching too much on very large browser viewports.
Try the describe for physically:
Resize your browser window to see how the describe changes with the viewport width.
As the viewport gets narrower, the content area, sidebar and navigation shrink proportionally. This facility honest until the browser width drops below around 1,000 pixels, at which point the three columns start to feel a small cramped. When you narrow the browser window additional, not working to around 600 pixels, the columns become so squashed with the intention of the copy inside becomes unreadable.


Making the describe responsive
Visibly, the fluid describe publicized above isn’t vacant to bring about water supply on the narrow viewports of mobile devices. This is where responsive layouts come in.
By making our describe responsive, we can reposition the various elements in the leaf based on the viewport width. Large desktop browser windows get the standard three-column describe, while narrow browser windows and mobile browsers hear a tweaked describe with the intention of is extra appropriate for their reduced width.
Understanding media queries
The key to building responsive layouts is CSS media queries. With media queries, you can make a bunch of CSS rulesets with the intention of release apply when the browser’s viewport is a fastidious width or height, or within a given width/height range. For example, by making a media query for viewports with the intention of are a reduced amount of than 700 pixels large, you can apply a set of custom CSS policy with the intention of involuntarily rearrange a leaf’s elements when the leaf is showed on narrow browser windows.
Media queries bring about in near all modern browsers, with the notable exception of Internet Explorer 8 and earlier.
Here are some media queries with the intention of you’re liable to use when building responsive layouts:
min-width: width- Applies when the viewport’s width is greater than or equal to width
max-width: width- Applies when the viewport’s width is a reduced amount of than or equal to width
min-device-width: width- Applies when the device’s cover width is greater than or equal to width
max-device-width: width- Applies when the device’s cover width is a reduced amount of than or equal to width
You can also specify exact width values using the properties width and device-width, although you’re extra liable to use the min/max versions to specify a range of values.
The difference between width and device-width is subtle but vital:
widthis the width of the browser viewport. On desktop browsers, this is typically smaller than the cover width. But, on mobile browsers, it’s typically larger than the cover width, since most mobile browsers use a “virtual viewport” with the intention of is larger than the cover, allowing the addict to zoom in and out, as water supply as pan around the viewport by dragging. For example, movable Safari uses a virtual viewport with the intention of is 980 pixels large, even though an iOS device’s cover is typically between 320 and 768 pixels large (in portrait mode). You’ll explore viewports in extra depth later in the article.device-widthis the width of the device’s cover. On a desktop machine, this in rank isn’t usually with the intention of vital to you as a web developer. On a mobile device, it can be helpful to know the cover width, since you can at that time adapt your describe to fit the device’s cover comfortably. But, if you’re using theviewportmetatag to ponytail the viewport width to the cover width (extra on this later) at that time you can just usewidthinstead ofdevice-widthto realize the constant result.
A additional subtle difference is with the intention of width (and min-width/max-width) is measured in CSS pixels, whereas device-width (and min-device-width/max-device-width) is measured in device pixels. When a leaf is zoomed in to 100% on a mobile device, 1 CSS pixel = 1 device pixel. But, if the leaf is zoomed out, 1 CSS pixel is smaller than 1 device pixel. To complicate things additional, the advent of high-density displays such as Apple’s retina show earnings with the intention of a “device pixel” may really represent extra than one genuine cover pixel! (The excellent news is with the intention of this really makes your go as web developer simpler, since you don’t call for to agonize about whether a device’s show is normal- or high-density.)
For a detailed conversation on this theme, see A pixel is not a pixel is not a pixel.
Adapting to viewports 1,000 pixels large or a reduced amount of
As mentioned earlier in the article, our fluid describe facility OK for large browser viewports, but the content, sidebar and nav columns start to look cramped when the viewport shrinks below 1,000 pixels large.
Let’s fix this. We’ll use a media query to detect if the viewport is a reduced amount of than or equal to 1,000 pixels large. If it is at that time we’ll place the nav on top of the sidebar instead of to the right. We can at that time make the nav, sidebar and content areas a small wider so with the intention of everything feels a reduced amount of cramped.
Here’s the CSS to do this — you can either add it to the end of foremost.css, place it in a break CSS file, or embed it into the leaf’s head section:
/* If the viewport width <= 1000 pixels ... */
@media cover and (max-width: 1000px) {
/* Make the foremost content a bit wider */
#content {
width: 75%;
}
/* Place the nav on top of the sidebar */
#nav, #sidebar {
width: 25%;
}
/* Adjust the sidebar margins */
#sidebar .inner {
margin-right: 0;
margin-top: 20px;
}
}
The rulesets inside our media query are triggered when the leaf is viewed on a cover, and when the viewport’s width is 1,000 pixels or a reduced amount of. The rulesets bring about like this:
- The initially ruleset stretches the foremost content’s width from 65% to 75%.
- The second ruleset puts the navigation on top of the sidebar by setting in cooperation elements to a width of 25%.
- The third ruleset removes the right margin from the sidebar content and adds some top margin instead, so with the intention of there is some vertical space between the nav and the sidebar.
Try out this new describe by clicking the button below:
You can see how it looks in the following figures. The top screenshot shows the first fluid describe with an 800-pixel-large viewport; the bottom screenshot shows the responsive describe at the constant width.


Adapting to viewports 700 pixels large or a reduced amount of
As the viewport narrows additional to around 700 pixels large, even our new two-column describe starts to looked cramped:

To solve this, we can use a additional media query to redraft the leaf additional into a release-column describe for these narrow viewport sizes. Here’s the CSS:
/* If the viewport width <= 700 pixels ... */
@media cover and (max-width: 700px) {
/* Make the foremost content fill the viewport width */
#content {
width: 100%;
}
/* Remove the foremost content right margin */
#content .inner {
margin-right: 0;
}
/* Place the nav above the foremost content */
#nav {
float: not any;
width: 100%;
margin-bottom: 20px;
}
/* Place the nav bits and pieces feature by feature */
#nav li {
float: missing;
width: 24%;
border-bottom: not any;
border-right: 1px levelheaded rgba(255,255,255,.5);
}
#nav li:last-child {
width: 27%;
border-right: not any;
}
#nav a {
copy-align: center;
padding-missing: 0;
}
/* Place the sidebar below the foremost content */
#sidebar {
float: not any;
apparent: in cooperation;
width: 100%;
margin: 20px 0;
}
}
These rulesets kick in when the leaf is viewed in a viewport a reduced amount of than or equal to 700 pixels large. The rulesets:
- Stretch the content column to the full width of the viewport, and remove the content’s right margin
- Reposition the nav menu so it’s above the foremost content, and stretch it to the full viewport width
- Make the nav bits and pieces run horizontally instead of vertically
- Reposition the sidebar so it’s below the foremost content, and stretch it to the full viewport width
Try out this new describe — click the button below, at that time resize the browser window so it’s a reduced amount of than 700 pixels large:
The figure below shows the new release-column describe in a narrow viewport:

Adapting to viewports 480 pixels large or a reduced amount of
We’ve now hard-pressed our describe about as far as we can, with everything in a release column. But, for very narrow browser windows, such as mobile phones, we can make one closing optimization: reduce or eliminate some of the padding and margin around the leaf elements.
Here’s the CSS:
/* If the viewport width <= 480 pixels ... */
@media cover and (max-width: 480px) {
body {
margin: 0;
}
#header .inner {
padding-top: 5px;
padding-bottom: 5px;
}
#header .inner, #content, #nav, #sidebar {
margin-bottom: 5px;
}
#nav ul {
padding: 5px 7px;
}
}
These rulesets remove the colorless margin around the outside of the leaf, and reduce the other colorless margins from 20 pixels to 5 pixels, once the viewport width drops to 480 pixels or a reduced amount of. They also reduce the padding on the header and nav elements vaguely.
Try out this describe in your browser. It should now look excellent at any browser width, from 1,600 pixels not working to 320 pixels:
The figures below show the describe on a 480-pixel-large browser, before and with applying the closing media query.


Dealing with mobile devices: the viewport meta tag
One of the foremost reasons to design a responsive describe with the intention of facility water supply on in cooperation large and tiny screens is, of course, to make your websites mobile-friendly. So how does our new responsive describe look on an iPhone, for example? Try out out the figure below:

As you can see, the iPhone’s browser has zoomed the leaf out, making the copy tiny and tough to scan. Our “1,000 pixels or a reduced amount of” media query has kicked in — sinking the leaf to two columns instead of three — but the “480 pixels or a reduced amount of” media query is not triggered, even though an iPhone’s cover is just 320 pixels large in portrait orientation, and 480 pixels large in landscape. What’s vacant on?
The high-classification “retina” show of the iPhone 4 (and, most likely, the imminent iPhone 5) is 640×960, not 320×480. But, for compatibility reasons, these devices soothe report their cover sizes as 320×480 pixels from a CSS perspective. For extra on this, scan A pixel is not a pixel is not a pixel.
The answer fabrication in the subtle difference between the viewport and the cover on mobile devices, which you looked at for a small time in Understanding media queries, earlier in the article.
The iPhone, by the feature of with most mobile browsers, uses a “virtual” viewport with the intention of is larger than the corporal cover. This allows mobile browsers to show web pages with the intention of are designed for larger, desktop browser windows. Initially, the viewport is zoomed out so with the intention of the whole leaf fills the cover. The addict can at that time pinch or dual-tap to zoom into specific areas of the viewport.
The iPhone’s viewport happens to be 980 pixels large, which facility fantastic for most websites with the intention of are designed to fit on a 1024×768 desktop show. This is why our “1,000 pixels or a reduced amount of” media query is triggered on the iPhone. But, we’ve built a responsive describe with the intention of is particularly designed to adapt to smaller screens, with the leaf fully zoomed in. How can we tell the iPhone with the intention of it should use a 320- or 480-pixel-large viewport with the intention of matches the cover size, rather than its 980-pixel-large virtual viewport?
This is where the viewport meta tag comes in. By regard this tag to a leaf’s <head>...</head> section, you can control the size of the mobile browser’s viewport.
In our case, we aspire the viewport’s width to match the device’s cover width, so with the intention of there’s a 1:1 ratio between the leaf’s CSS pixels and the device’s cover pixels. We can do this using two values in the viewport tag: initial-extent and maximum-extent. Here’s how to do it:
<meta first name="viewport" content="initial-extent=1, maximum-extent=1" />
initial-extent=1ensures with the intention of the leaf, when initially showed, is fully zoomed in, so with the intention of the viewport’s width matches the device’s cover width in portrait orientation — for example, 320 pixels on an iPhone and 768 pixels on an iPad.maximum-extent=1prevents the device from zooming in additional than 1:1 when rotating to landscape orientation. In other words, it forces the iPhone viewport’s width to increase to 480 pixels in landscape mode. If we didn’t contain themaximum-extentregard at that time the viewport would be 320 pixels large in in cooperation portrait and landscape orientations. Now and again this might be what you aspire, but for our responsive describe, it would blow up the content too much in landscape mode.
Now, when viewing our leaf on an iPhone in portrait orientation, the viewport is 320 pixels large. When viewing in landscape, it’s 480 pixels large. This triggers our “480 pixels or a reduced amount of” media query successfully, as you can see in the following figure:

viewport meta tag by the feature of with the initial-extent and maximum-extent values, we can advertise something to someone mobile browsers to match their viewport’s width to the device’s width, thereby triggering the right media query.If you have a mobile device such as an iPhone, iPad or Android buzz, you can try out this closing describe for physically by tapping the button below:
You can also control the viewport’s width explicitly using values such as width=500 (for 500 pixels) and width=device-width (for the width of the device’s cover in portrait orientation). Depending on the nature of your describe, setting the width explicitly might ensemble you better. See the Safari Web Content Guide for extra in rank.
Summary
In this article you’ve explored the concept of responsive web design, and tried out a few responsive design techniques. You’ve looked at:
- The vital thought behind responsive web design: making websites with the intention of seamlessly adapt themselves to different cover sizes and devices.
- The subtle difference between the terms “responsive web design” and “adaptive web design”.
- How to convert a standard fluid describe into a responsive describe with the intention of adapts to various different browser sizes.
- CSS media queries, and their role in responsive layouts.
- How to set the size of a mobile browser’s viewport by using the
viewportmetatag.
I hope you’ve found the article helpful, and with the intention of it has taken some of the mystery out of responsive web design. Have fun!
