Responsive / responsible development

21 min. read

Caution! This article is 7 years old. It may be obsolete or show old techniques. It may also still be relevant, and you may find it useful! So it has been marked as deprecated, just in case.


What do you understand by responsive?

Responsive development is about adapting to the unknown. It's a way of re-wiring our brains to think about one-web.

Content is like water

But, does one size fit it all always?

Think about how your visitors will use your site. If you visit an airport site from your phone, you may want to know how to access the parking area, or get information on departures/arrivals, while if you are on a desktop computer, you may want to print your boarding pass.

Dabbling sites like CodePen may not need to be responsive. A blog is an example of a site that could benefit from being responsive. If you have a webapp though, or if you need integration with the device (like having access to the camera or phone contacts), going native for mobile or hybrid could be the best option.

Graceful degradation and progressive enhancement

Graceful degradation is older than progressive enhancement. Nowadays, developers prefer to stick to progressive enhancement.

Graceful degradation vs progressive enhancement
Img. 1: Source: Unlocking Mobile ROI

Graceful degradation

In graceful degradation, you start with the whole picture, and provide simpler defaults for edge cases. Smashing Magazine has an article on techniques to achieve this. For example:

<script type="text/javascript" src="/menu.js"></script>
  <ul id="menu">
    <li><a href="/">Home</a></li>
    <li><a href="/products/">Products</a></li>
    <li><a href="/services/">Services</a></li>

The menu.js file contains some fancy interactions, but you should provide basic functionality inside the <noscript> tag, for users who may have JavaScript disabled.

Progressive enhancement

In progressive enhancement, you start with the basics and add complexity, for example through media queries. This is the preferred method. For example:

.box {
  background-color: red;  /* fallback */
  background-color: rgba(255, 0, 0, 0.5);

Browsers that don't support rgba would show a red background. This is because CSS is error tolerant like HTML. If a browser does not understand an HTML tag or a CSS property, it ignores it. You can check which browsers support what in

Mobile/wearable-first development follows the progressive enhancement approach, and it's preferred over desktop-first development (graceful degradation).

Desktop-first vs mobile-first
Img. 2: Source:

Let's DO THIS!

How to make a site responsive is a wide topic that requires much more than just code, but also thinking about who is going to use your site and how. However, it can be trimmed down to three basic “musts”:

  • media queries: Media queries allow the page to use different CSS style rules based on characteristics of the device the site is being displayed on, most commonly the width of the browser.
  • fluid grids: The fluid grid concept calls for page element sizing to be in relative units like percentages or ems, rather than absolute units like pixels or points.
  • flexible images and media: Flexible media is also sized in relative units (up to 100%), so as to prevent them from displaying outside their containing element.

Let's look at them more closely:

1. Media queries

From the words:

  • media: @media screen, @media print, etc.
  • query: (min-width:768px), (min-aspect-ratio: 1/1), etc.

Beware: Even if you have media queries in your CSS, they won't work if you don't use:

<meta name="viewport" content="initial-scale=1.0, width=device-width"/>

This tells viewport-aware browsers that a website shouldn’t be scaled down, and that the width of the browser window should be treated the same as the overall device width.


Let's say we have this simple markup:

<div class="container">
  <div class="sidebar">Sidebar</div>
  <div class="content">Content</div>
Demo - Desktop
Img. 3: Desktop view
Demo - Mobile
Img. 4: Mobile view

If we use a desktop-first approach (demo):

.sidebar {
  float: left;
  width: 25%;

.content {
  float: left;
  width: 75%;

@media (max-width: 40em) {
  .content {
    float: none;
    width: auto;

Here, max-width: 40em is our breakpoint for smaller viewports: under this width, the styles inside the @media brackets will be applied. Over this width, the default styles (the ones outside the media query) will be applied.

The problem with this approach is that, in the media query for smaller viewports, we will have to undo the floats for smaller screens.

Also, html elements have a width of auto by default, but because we had to set it to something else in our default styles (for bigger screens), it must be reset as well for smaller viewports.

In other words, for smaller and potentially less powerful devices, we are adding more code instead of reducing it.

If we use a mobile-first approach (demo):

@media (min-width: 40em) {
  .sidebar {
     float: left;
     width: 25%;

  .content {
     float: left;
     width: 75%;

Now, for small viewports we do nothing, so the default browser styles will be applied. Only if the viewport is bigger (for viewports with a min-width of 40em) we add more code.

Also, if we wanted to add a new background image for some element, but the image was too big for a small device, we could add the background image to the element inside a media query, and the browser wouldn't download the resource for smaller devices, while it would for bigger devices. This is very helpful for small devices on a bad connection, for example.

With media queries:

  • You can use your content to set the breakpoints.
  • Only the minimum required files are loaded.
  • Keeps the mobile solution lightweight.

Media queries are supported in all major browsers except IE8 and below.

2. Fluid Layout

You may want to check out this nice resource on Multi-Device Layout Patterns by Luke Wroblewski.

  • Use ems and percentages for your elements. Ideally, ems to size typography and vertical measurements, and percentages for layout and horizontal measurements.
  • Use ems for your breakpoints instead of pixels. This helps you account for varying browser zoom levels. PXtoEM is a nice conversion tool.
  • On small screens, the content fits the viewport, but remember to give it enough padding to breath.
  • On bigger screens, keep a confortable width for reading, by setting the max-width property to about 30 - 40em.
  • Place the relevant content at the top, and the controls at the bottom. This is a common industrial design convention that’s now making its way to the software. We don’t want our fingers covering the content when we are interacting with the site.
  • For tablet-like sizes, favor the sides and corners and avoid the center.

3. Flexible Images

When talking about responsible web development, it is impossible not to talk about performance. Images are the elephant in the room, as they are the main source of performance problems.

This is a long topic, not covered fully in this article (search for art direction, adaptive images, picture element, etc.). There is still no solution for responsive images. In the meanwhile, you can have fluid images and media with:

img {
  height: auto;
  max-width: 100%;


  • Avoid images if possible.
  • If not possible, prefer vector images (SVG) over raster images (GIF, PNG, JPG). Vector images are basically text and can be gzipped considerably more than normal images (around 10% to 90% ratio in average).
  • If not possible, you could try CSS gradients for simple backgrounds. Lea Verou's gallery is a great resource and it also tells you the size of the code as you type.
  • If not possible, use PNG and flat colors. If the image is complex, like a photograph, use JPG. In Photoshop, you can use save for web to optimize PNG and JPG, or take the ones that GTmetrix generates for you.
  • For logos and icons, use SVG and avoid font-icons as well. IcoMoon is a great tool to generate them.
  • Load the less relevant images for bigger screens only, through media queries.
  • If all this fails, consider creating multiple versions of your graphics. This can greatly affect the speed at which your design loads on smaller screens.
Adaptive SVG logo
Img. 5: PNG (left) vs JPG (right). For images with flat colors, no gradients and sharp borders, prefer PNG over JPG.
Adaptive SVG logo
Img. 6: Example of adaptive logo made in SVG. You can achieve this through media queries inside the SVG. Image source:

Other best practices

Responsive navigation

There are a lot of ergonomics limitations to think about in smaller screens.

On a smartphone:

  • Horizontal space is limited, we can fit about 4 links across. Hide the menu items that you think your mobile users won't use.
  • Vertical menus take up a lot of space. Reposition the navigation with CSS without needing to alter the HTML.
  • Show only the most important information first.

On touch screens in general:

  • Tap size should be at least 3em.
  • Give enough space for fingers to reach. Thumbs move in diagonal.
  • Provide feedback when screen is touched.
  • Minimize text input.
  • Keep the most content visible and accessible through one click, two-clicks maximum.


  • Don't make your users download a lot of fonts, keep it to no more than one for the copy, one for titles, and maybe one for code snippets.
  • Google Fonts optimizes font delivery according to the user browser and shows you the impact on page load time.
  • A font-size of at least 16px (1em) and a line height of 1.5 are good for readability.
  • Resize the type for bigger screens and have the relevant elements sized in ems, so that the layout adapts to the font.

Responsive tables

The other elephant in the room, together with images. Several techniques are discussed in this CSS-Tricks article about responsive data tables.

Reset stylesheets

Different browsers behave differently:

.robot {
  border-radius: 50%;
  border: 1em dotted grey;


Cross-browser optimization
Img. 7: A dotted-border-radiused element in different browsers.

And different O.S. have different defaults. For example, the default monospaced font in Windows would be Courier, Ubuntu-mono in Ubuntu, and Monaco in a Mac. This could break your layout.

The first example (cross-browser dotted-border-radiused elements) could only be fixed by using an SVG. The second example (default monospaced font), by loading a specific font for code snippets. But there are other defaults that can be accessed and reset.

There are several ways to reset these defaults. Long ago, developers used this simple one, but it was left behind because it is performance-heavy, and does not really reset your styles:

/* Please never do this */
* {
  margin:  0;
  padding: 0;

Eric Meyer created a reset stylesheet that became very popular and widely used a while ago.

Nowadays, a better solution is normalize, which, together with Paul Irish's html5 boilerplate, fixes several well-known cross-browser issues and documents them.

About responsibility. Is this enough?

72% of responsive sites send the same assets to mobile sites as they do to desktop sites. Only 6% optimize things for specific devices (source).

As a summary, these are some basic things to keep in mind:

  • Keep it simple and light (size < 1 Mb, load time < 2-3 s)
  • Reduce the number of images
  • Reduce image dimensions
  • Fewer files, fewer http requests
  • Include your JavaScript files at the end of the document and load them asynchronously (<script async src="file.js" />)
  • For the parts of your assets/resources that won't change much, serve them from a CDN.
  • For the parts that change the most and can't benefit from browser caching, minify, concatenate and gzip them. You can automate this process along with other tasks using a service like Grunt or Gulp.
  • Little or no client-side processing. Keeping our functionality independent of JavaScript improves performance. All your users are non-JavaScript users while a page is downloading.
  • Load the essential parts of a page first. Then load the rest of non-essential elements in the background after all the core content has loaded.