The State Of Responsive Web Design

Advertisement

Responsive Web design has been around for some years now, and it was a hot topic in 2012. Many well-known people such as Brad Frost and Luke Wroblewski have a lot of experience with it and have helped us make huge improvements in the field. But there’s still a whole lot to do.

In this article, we will look at what is currently possible, what will be possible in the future using what are not yet standardized properties (such as CSS Level 4 and HTML5 APIS), and what still needs to be improved. This article is not exhaustive, and we won’t go deep into each technique, but you’ll have enough links and knowledge to explore further by yourself.

The State Of Images In Responsive Web Design

What better aspect of responsive Web design to start off with than images? This has been a major topic for a little while now. It got more and more important with the arrival of all of the high-density screens. By high density, I mean screens with a pixel ratio higher than 2; Apple calls these Retina devices, and Google calls them XHDPI. In responsive Web design, images come with two big related challenges: size and performance.

Most designers like pixel perfection, but “normal”-sized images on high-density devices look pixelated and blurry. Simply serving double-sized images to high-density devices might be tempting, right? But that would create a performance problem. Double-sized images would take more time to load. Users of high-density devices might not have the bandwidth necessary to download those images. Also, depending on which country the user lives in, bandwidth can be pretty costly.

The second problem affects smaller devices: why should a mobile device have to download a 750-pixel image when it only needs a 300-pixel one? And do we have a way to crop images so that small-device users can focus on what is important in them?

Two Markup Solutions: The <picture> Element and The srcset Attribute

A first step in solving the challenge of responsive images is to change the markup of embedded images on an HTML page.

The Responsive Images Community Group1 supports a proposal for a new, more flexible element, the <picture>2 element. The concept is to use the now well-known media queries to serve different images to different devices. Thus, smaller devices would get smaller images. It works a bit like the markup for video, but with different images being referred to in the source element.

The code in the proposed specification looks like this :

<picture width="500"  height="500">     
  <source  media="(min-width: 45em)" src="large.jpg">
  <source  media="(min-width: 18em)" src="med.jpg">
  <source  src="small.jpg">
  <img  src="small.jpg" alt="">
  <p>Accessible  text</p>
</picture>

If providing different sources is possible, then we could also imagine providing different crops of an image to focus on what’s important for smaller devices. The W3C’s “Art Direction3” use case shows a nice example of what could be done.

Picture element used for artistic direction4
(Image: Egor Pasko5)

The solution is currently being discussed by the W3C Responsive Images Community Group6 but is not usable in any browser at the moment as far as we know. A polyfill named Picturefill7 is available, which does pretty much the same thing. It uses a div and data-attribute syntax for safety’s sake.

A second proposal for responsive images markup was made to the W3C by Apple and is called “The srcset Attribute8”; its CSS Level 4 equivalent is image-set()9. The purpose of this attribute is to force user agents to select an appropriate resource from a set, rather than fetch the entire set. The HTML syntax for this proposal is based on the <img> tag itself, and the example in the specification looks like this:

<img  alt="The Breakfast Combo" 
  src="banner.jpeg"
  srcset="banner-HD.jpeg  2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">

As you can see, the syntax is not intuitive at all. The values of the tag consist of comma-separated strings. The values of the attribute are the names or URLs of the various images, the pixel density of the device and the maximum viewport size each is intended for.

In plain English, this is what the snippet above says:

  • The default image is banner.jpeg.
  • Devices that have a pixel ratio higher than 2 should use banner-HD.jpeg.
  • Devices with a maximum viewport size of 100w should use banner-phone.jpeg.
  • Devices with a maximum viewport size of 100w and a pixel ratio higher than 2 should use banner-phone-HD.jpeg.

The first source is the default image if the srcset attribute is not supported. The 2x suffix for banner-HD.jpeg means that this particular image should be used for devices with a pixel ratio higher than 2. The 100w for banner-phone.jpeg represents the minimum viewport size that this image should be used for. Due to its technical complexity, this syntax has not yet been implemented in any browser.

The syntax of the image-set() CSS property works pretty much the same way and enables you to load a particular background image based on the screen’s resolution:

background-image: image-set(  "foo.png" 1x,
  "foo-2x.png"  2x,
  "foo-print.png"  600dpi );

This proposal is still a W3C Editor’s Draft. For now, it works in Safari 6+ and Chrome 21+.

Image Format, Compression, SVG: Changing How We Work With Images on the Web

As you can see, these attempts to find a new markup format for images are still highly experimental. This raises the issue of image formats themselves. Can we devise a responsive solution by changing the way we handle the images themselves?

The first step would be to look at alternative image formats that have a better compression rate. Google, for example, has developed a new image format named WebP10, which is 26% smaller than PNG and 25 to 34% smaller than JPEG. The format is supported in Google Chrome, Opera, Yandex, Android and Safari and can be activated in Internet Explorer using the Google Chrome Frame11 plugin. The main problem with this format is that Firefox does not plan to implement it. Knowing this, widespread use is unlikely for now.

Another idea that is gaining popularity is progressive JPEG images. Progressive JPEG images are, as the name suggests, progressively rendered. The first rendering is blurry, and then the image gets progressively sharper as it renders. Non-progressive JPEG images are rendered from top to bottom. In her article “Progressive JPEGs: A New Best Practice12,” Ann Robson argues that progressive JPEGs give the impression of greater speed than baseline JPEGs. A progressive JPEG gives the user a quick general impression of the image before it has fully loaded. This does not solve the technical problems of performance and image size, though, but it does improve the user experience.

Another solution to the problems of performance and image size is to change the compression rate of images. For a long time, we thought that enlarging the compression rate of an image would damage the overall quality of the image. But Daan Jobsis has done extensive research on the subject and has written an article about it, “Retina Revolution13.” In his experiments, he tried different image sizes and compression rates and came up with a pretty interesting solution. If you keep the image dimensions twice the displayed ones but also use a higher compression rate, then the image will have a smaller file size than the original, but will still be sharp on both normal and high-density screens. With this technique, Jobsis cut the weight of the image by 75%.

Image compression example14
Daan Jobsis’ demonstration of image compression.

Given the headaches of responsive images, the idea of gaining pixel independence from images wherever possible is seducing more and more designers and developers. The SVG format, for example, can be used to create all of the UI elements of a website and will be resolution-independent15. The elements will scale well for small devices and won’t be pixellated on high-density devices. Font icons16 are another growing trend. They involve asigning icon glyphs to certains characters of the font (like the Unicode Private Area ones), giving you the flexibility of fonts. Unfortunately, the solution doesn’t work with pictures, so a viable markup or image format is eagerly expected.

Responsive Layout Challenge: Rearrange And Work With Content Without Touching the HTML?

Let’s face it, the fluid grids made of floats and inline blocks that we use today are a poor patch waiting for a better solution. Working with layout and completely rearranging blocks on the page for mobile without resorting to JavaScript is a nightmare right now. It’s also pretty inflexible. This is particularly significant on websites created with a CMS; the designer can’t change the HTML of every page and every version of the website. So, how can this be improved?

Four CSS3 Layout Solutions That Address the Flexible Layout Problem

The most obvious possible solution is the CSS3 flexible box layout model17 (or “flexbox”). Its current status is candidate recommendation, and it is supported in most major mobile browsers and desktop browsers18 (in IE starting from version 10). The model enables you to easily reorder elements on the screen, independent of the HTML. You can also change the box orientation and box flow and distribute space and align according to the context. Below is an example of a layout that could be rearranged for mobile. The syntax would look like this:

.parent {
  display: flex;
  flex-flow: column; /* display items in columns */
}

.children {
  order: 1; /* change order of elements */
}

Flexbox as an example19

The article “CSS3 Flexible Box Layout Explained20” will give you a deeper understanding of how flexbox works.

Another solution quite close to the flexbox concept of reordering blocks on the page, but with JavaScript, is Relocate21.

A second type of layout that is quite usable for responsive design today is the CSS3 multiple-column layout. The module is at the stage of candidate recommendation, and it works pretty well in most browsers22, expect for IE 9 and below. The main benefit of this model is that content can flow from one column to another, providing a huge gain in flexibility. In terms of responsiveness, the number of columns can be changed according to the viewport’s size.

Setting the size of the columns and letting the browser calculate the number of columns according to the available space is possible. Also possible is setting the number of columns, with the gaps and rules between them, and letting the browser calculate the width of each column.

CSS3 Multiple Column layout23

The syntax looks like this:

.container {
  column-width: 10em ; /* Browser will create 10em columns. Number of columns would depend on available space. */
}

.container {
  columns: 5; /* Browser will create 5 columns. Column size depends on available space. */
  column-gap: 2em;
}

To learn more, read David Walsh’s article “CSS Columns24.”

A third CSS3 property that could gain more attention in future is the CSS3 grid layout25. This gives designers and developers a flexible grid they can work with to create different layouts. It allows content elements to be displayed in columns and rows without a defined structure. First, you would declare a grid on the container, and then place all child elements in this virtual grid. You could then define a different grid for small devices or change the position of elements in the grid. This allows for enormous flexibility when used with media queries, changes in orientation and so on.

The syntax looks like this (from the 2 April 2013 working draft):

 .parent {
   display: grid; /* declare a grid */
   grid-definition-columns: 1stgridsize  2ndgridsize …;
   grid-definition-rows: 1strowsize  2ndrowsize …;
}

.element {
   grid-column: 1; 
   grid-row: 1
}

.element2 {
   grid-column: 1; 
   grid-row: 3;
}

To set the sizes of columns and rows, you can use various units, as detailed in the specification26. To position the various elements, the specification says this: “Each part of the game is positioned between grid lines by referencing the starting grid line and then specifying, if more than one, the number of rows or columns spanned to determine the ending grid line, which establishes bounds for the part.”

The main problem with this property is that it is currently supported only in IE 1027. To learn more about this layout, read Rachel Andrew’s “Giving Content Priority With CSS3 Grid Layout28.” Also, note that the specification and syntax for grid layouts changed on 2 April 2013. Rachel wrote an update on the syntax, titled “CSS Grid Layout: What Has Changed?29

The last layout that might become useful in future if implemented in browsers is the CSS3 template layout30. This CSS3 module works by associating an element with a layout “name” and then ordering the elements on an invisible grid. The grid may be fixed or flexible and can be changed according to the viewport’s size.

The syntax looks like this:

.parent {
   display: "ab"
            "cd" /* creating the invisible  grid */
}

.child1 {
   position: a;
}

.child2 {
   position: b;
}

.child3 {
   position: c;
}

.child4 {
   position: d;
} 

This renders as follows:

CSS3 template layout31

Unfortunately, browser support for this CSS3 module is currently null. Maybe someday, if designers and developers show enough interest in this specification, some browser vendors might implement it. For the moment, you can test it out with a polyfill32.

Viewport-Relative Units and the End of Pixel-Based Layout

Viewport-based percentage lengths33 — vw, vh, vm, vmin and vmax — are units measured relative to the dimensions of the viewport itself.

One vw unit is equal to 1% of the width of the initial containing block. If the viewport’s width is 320, then 1 vw is 1 × 320/100 = 3.2 pixels.

The vh unit works the same way but is relative to the height of the viewport. So, 50 vh would equal 50% of the height of the document. At this point, you might wonder what the difference is with the percentage unit. While percentage units are relative to the size of the parent element, the vh and vw units will always be relative to the size of the viewport, regardless of the size of their parents.

This gets pretty interesting when you want to, for example, create a content box and make sure that it never extends below the viewport’s height so that the user doesn’t have to scroll to find it. This also enables us to create true 100%-height boxes without having to hack all of the elements’ parents.

The vmin unit is equal to the smaller of vm or vh, and vmax is equal to the larger of vm or vh; so, those units respond perfectly to changes in device orientation, too. Unfortunately, for the moment, those units are not supported in Android’s browser34, so you might have to wait a bit before using them in a layout.

A Word on Adaptive Typography

The layout of a website will depend heavily on the content. I cannot conclude a section about the possibilities of responsive layout without addressing typography. CSS3 introduces a font unit that can be pretty handy for responsive typography: the rem unit35. While fonts measured in em units have a length relative to their parent, font measured in rem units are relative to the font size of the root element. For a responsive website, you could write some CSS like the following and then change all font sizes simply by changing the font size specified for the html element:

html {
   font-size: 14px;
}

p {
   font-size: 1rem /* this has 14px */
}

@media screen and (max-width:380px) {
   html {
      font-size: 12px; /* make the font smaller for mobile devices */
   }

   p {
      font-size: 1rem /* this now equals 12px */
   }
}

Except for IE 8 and Opera mini, support for rem36 is pretty good. To learn more about rem units, read Matthew Lettini’s article “In Defense of Rem Units37.”

A Better Way To Work Responsively With Other Complex Content

We are slowly getting better at dealing with images and text in responsive layouts, but we still need to find solutions for other, more complex types of content.

Dealing With Forms on a Responsive Website

Generally speaking, dealing with forms, especially long ones, in responsive Web design is quite a challenge! The longer the form, the more complicated it is to adapt to small devices. The physical adaptation is not that hard; most designers will simply put the form’s elements into a single column and stretch the inputs to the full width of the screen. But making forms visually appealing isn’t enough; we have to make them easy to use on mobile, too.

For starters, Luke Wroblewski advises38 to avoid textual input and instead to rely on checkboxes, radio buttons and select drop-down menus wherever possible. This way, the user has to enter as little information as possible. Another tip is not to make the user press the “Send” button before getting feedback about the content of their submission. On-the-fly error-checking is especially important on mobile, where most forms are longer than the height of the screen. If the user has mistyped in a field and has to send the form to realize it, then chances are they won’t even see where they mistyped.

In the future, the new HTML5 form inputs and attributes will be a great help to us in building better forms, without the need for (much) JavaScript. For instance, you could use the required attribute39 to give feedback about a particular field on the fly. Unfortunately, support for this on mobile40 devices is poor right now. The autocomplete attribute41 could also help to make forms more responsive.

A mobile phone is a personal possession, so we can assume that data such as name and postal address will remain consistent. Using the autocomplete HTML5 attribute, we could prefill such fields so that the user doesn’t have to type all of that information over and over. There is also a whole list of new HTML5 inputs42 that can be used in the near future to make forms more responsive.

Dates in form elements are a good example of what can be improved with HTML5. We used to rely on JavaScripts to create date-pickers. Those pickers are quite usable on big desktop screens but very hard to use on touch devices. Selecting the right date with a finger is difficult when the touch zones are so small.

Different picker examples43
How am I supposed to select a date when my finger is touching three dates at the same time?

A promising solution lies in the new HTML5 input type="date"44, which sets a string in the format of a date. The HTML5 input type="datetime"45 sets a string in the format of a date and time. The big advantage of this method is that we let the browser decide which UI to use. This way, the UI is automatically optimized for mobile phones. Here is what an input type="date" looks like on the desktop, on an Android phone and tablet (with the Chrome browser), and on the iPhone and iPad.

Mobile input type=date rendering46
Renderings of input type="date" on different mobile devices.

Note that the screenshots were taken in my browser and on the Android phone, so the language automatically adapted to the system language (French). By using native components, you no longer have to adapt the language into different versions of the website.

For now, support for input type="date"47 on the desktop is absent except in Opera and Chrome. Native Android browsers don’t support it at all, but Chrome for Android does, and so does Safari on iOS. A lot still has to get done in order for us to be able to use this solution on responsive websites. Meanwhile, you could use a polyfill such as Mobiscroll48 for mobile browsers that don’t support it natively.

Apart from these HTML5 input solutions, attempts have been made to improve other design patterns, such as passwords on mobile49 and complex input formatting using masks50. As you will notice, these are experimental. The perfect responsive form does not exist at the moment; a lot still has to be done in this field.

Dealing With Tables on a Responsive Website

Another content type that gets pretty messy on mobile and responsive websites is tables. Most table are oriented horizontally and present a lot of data at once, so you can see how getting it right on a small screen is pretty hard. HTML tables are fairly flexible — you can use percentages to change the width of the columns — but then the content can quickly become unreadable.

No one has yet found the perfect way to present tables, but some suggestions have been made.

One approach is to hide what could be considered “less important” columns, and provide checkboxes for the user to choose which columns to see. On the desktop, all columns would be shown, while on mobile, the number of columns shown would depend on the screen’s size. The Filament Group explains this approach51 and demonstrates it52 in one of its articles. The solution is also used in the table column toggle on jQuery Mobile53.

Responsive table examples54
Some examples of responsive tables.

A second approach plays with the idea of a scrollable table. You would “pin” a single fixed-size column on the left and then leave a scroll bar on a smaller part of the table to the right. David Bushell implements this idea55 in an article, using CSS to display all of the content in the <thead> on the left side of the table, leaving the user to scroll through the content on the right. Zurb uses the same idea but in a different way for its plugin56. In this case, the headers stay at the top of the table, and the table is duplicated with JavaScript so that only the first column is shown on the left, and all other columns are shown on the right with a scroll bar.

Responsive table overflow example57
Two examples of scrollable responsive tables

The big issue with scroll bars and CSS properties such as overflow: auto is that many mobile devices and tablets simply won’t display a visible scroll bar. The right area of the table will be scrollable, but the user will have no visual clue that that’s possible. We have to find some way to indicate that more content lies to the right.

A third approach is to reflow a large table and split up the columns into what essentially looks like list items with headings. This technique is used in the “reflow mode”58 on jQuery Mobile and was explained by Chris Coyier in his article “Responsive Data Tables59.”

Responsive table reflow example60
Reflowing a table responsively

Many other techniques61 exist. Which to use depends heavily on your project. No two projects are the same, so I can only show you how other people have dealt with it. If you come up with a nice solution of your own, please share it with the world in the comments below, on Twitter or elsewhere. We are in this boat together, and tables suck on mobile, really, so let’s improve them together!

Embedding Third-Party Content: The Responsive Iframe Problem

Many websites consist of embedded third-party content: YouTube or Vimeo videos, SlideShare presentations, Facebook applications, Twitter feeds, Google Maps and so on. A lot of those third parties make you use iframes to embed their content. But let’s face it: iframes are a pain to deal with in responsive design. The big problem is that iframes force a fixed width and height directly in your HTML code. Forcing a 100% width on the iframe would work, but then you would lose the ratio of the embedded content. To embed a video or slideshow and preserve the original ratio, you would have to find a workaround.

An HTML and CSS Workaround

Thierry Koblentz62 has written a good article titled “Creating Intrinsic Ratios for Video63,” in which he proposes a way to embed responsive videos using a 16:9 ratio. This solution can be extended to other sorts of iframe content, such as SlideShare presentations and Google Maps. Koblentz wraps the iframe in a container with a class that we can target in CSS. The container makes it possible for the iframe to resize fluidly, even if the iframe has fixed pixel values in the HTML. The code, adapted by Anders M. Andersen,64 looks like this:

 .embed-container  {
   position: relative;
   padding-bottom: 56.25%; /* 16:9 ratio */
   padding-top: 30px; /* IE 6 workaround*/
   height: 0;
   overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
   position: absolute;
   top: 0;
   left: 0;
   width: 100%;
   height: 100%;
}

This will work for all iframes. The only potential problem is that you will have to wrap all of the iframes on your website in a <div class="embed-container"> element. While this would work for developers who have total control over their code or for clients who are reasonably comfortable with HTML, it wouldn’t work for clients who have no technical skill. You could, of course, use some JavaScript to detect iframe elements and automatically embed them in the class. But as you can see, it’s still a major workaround and not a perfect solution.

Dealing With Responsive Video In Future

HTML5 opens a world of possibilities for video — particularly with the video element65. The great news is that support for this element is amazingly good for mobile devices66! Except for Opera Mini, most major browsers support it. The video element is also pretty flexible. Presenting a responsive video is as simple as this:

video {
   max-width: 100%;
   height: auto;
}

You’re probably asking, “What’s the problem, then?”

The problem is that, even though YouTube or Vimeo may support the video element, you still have to embed videos using the ugly iframe method. And that, my friend, sucks. Until YouTube and Vimeo provide a way to embed videos on websites using the HTML5 video tag, we have to find workarounds to make video embedding work on responsive websites. Chris Coyier created such a workaround as a jQuery plugin called FitVids.js67. It uses the first technique mentioned above: creating a wrapper around the iframe to preserve the ratio.

Embedding Google Maps

If you embed a Google Map on your website, the technique described above with the container and CSS will work. But, again, it’s a dirty little hack. Moreover, the map will resize in proportion and might get so tiny that the map loses the focus area that you wanted to show to the user. The Google Maps’ page for mobile68 says that you can use the static maps API69 for mobile embedding. Using a static map would indeed make the iframe problems go away. Brad Frost wrote a nice article about, and created a demo of, adaptive maps70, which uses this same technique. A JavaScript detects the screen’s size, and then the iframe is replaced by the static map for mobile phones. As you can tell, we again have to resort to a trick to deal with the iframe problem, in the absence of a “native” solution (i.e. from Google).

We Need Better APIs

And now the big question: Is there a better way? The biggest problem with using iframes to embed third-party content responsively is the lack of control over the generated code. Developers and designers are severely dependent on the third party and, by extension, its generated HTML. The number of websites that provide content to other websites is growing quickly. We’ll need much better solutions than iframes to embed this content.

Let’s face it: embedding Facebook’s iframe is a real pain. The lack of control over the CSS can make our work look very sloppy and can even sometimes ruin the design. The Web is a very open place, so perhaps now would be a good time to start thinking about more open APIs! In the future, we will need APIs that are better and simpler to use, so that anyone can embed content flexibly, without relying on unresponsive fixed iframes. Until all of those very big third parties decide to create those APIs, we are stuck with sloppy iframes and will have to resort to tricks to make them workable.

Responsive Navigation: An Overview Of Current Solutions

Another big challenge is what to do with navigation. The more complex and deep the architecture of the website, the more inventive we have to be.

An early attempt to deal with this in a simple way was to convert the navigation into a dropdown menu71 for small screens. Unfortunately, this was not ideal. First, this solution gets terribly complicated with multiple-level navigation. It can also cause some problems with accessibility. I recommend “Stop Misusing Select Menus72” to learn about all of the problems such a technique can create.

Some people, including Brad Frost73 and Luke Wroblewski, have attempted to solving this problem. Brad Frost compiled some of his techniques on the website This Is Responsive74, under the navigation section.

Toggle navigation involves hiding the menu for small devices, displaying only a “menu” link. When the user clicks on it, all of the other links appear as block-level elements below it, pushing the main content below the navigation.

A variant of this, inspired by some native application patterns, is off-canvas75 navigation. The navigation is hidden beneath a “menu” link or icon. When the user clicks the link, the navigation slides out as a panel from the left or right, pushing the main content over.

Toggle navigation example76
Some examples of toggle navigation

The problem with these techniques is that the navigation remains at the top of the screen. In his article “Responsive Navigation: Optimizing for Touch Across Devices77,” Luke Wroblewski illustrates which zones are easily accessible for different device types. The top left is the hardest to get to on a mobile device.

Easy touch access for mobile and tablet78
Easily accessible screen areas on mobile phones and tablets, according to Luke Wroblewski79.

Based on this, Jason Weaver created some demos80 with navigation at the bottom. One solution is a footer anchor81, with navigation put at the bottom of the page for small devices, and a “menu” link that sends users there. It uses the HTML anchor link system.

Many82 other attempts83 have been made84 to solve the navigation problem in responsive Web design. As you can see, there is not yet a perfect solution; it really depends on the project and the depth of the navigation. Fortunately for us, some of the people who have tried to crack this nut have shared their experiences with the community.

Another unsolved issue is what icon to use to tell the user, “Hey! There’s a menu hidden under me. Click me!” Some websites have a plus symbol (+), some have a grid of squares, other have what looks like an unordered list, and some have three lines (aka the burger icon).

Some responsive icons example85
To see these icons used on real websites, have a look at “We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design86.”

The main problem is figuring out which of these icons would be the most recognizable to the average user. If we all agreed to use one of them, users would be trained to recognize it. The problem is which to choose? I really would like to know which icon you use, so don’t hesitate to share it in the comments below.

Mobile Specificities: “Is The User On A Mobile Device? If So, What Can It Do?”

Mobile and tablet devices are a whole new world, far removed from desktop computers, with their own rules, behaviors and capabilities. We might want to adapt our designs to this new range of capabilities.

Detecting Touch Capabilities With Native JavaScript

Apart from screen size, I bet if you asked what is the main difference between desktop and mobile (including tablets), most people would say touch capability. There is no mouse on a mobile phone (no kidding!), and except for some rare hybrid devices into which you can plug a mouse, you can’t do much with mouse events on a tablet. This means that, depending on the browser, the :hover CSS pseudo-class might not work. Some browsers are clever enough to provide a native fallback for the hover event by translating it into a touch event. Unfortunately, not all browsers are so flexible. Creating a design that doesn’t depend on hidden elements being revealed on :hover events would be wise.

Catching touch events could also be another solution. A W3C working group has started working on a touch event specification87. In the future, we will be able to catch events such as touchstart, touchmove and toucheend. We will be able to deal with these events directly in JavaScript without requiring a third-party framework such as Hammer.js88 or jGestures89. But JavaScript is one thing — what about CSS?

CSS Level 4 “Pointer” Media Query

CSS Level 4 specifies a new media query called “pointer”90, which can be used to query the presence and accuracy of a pointing device, such as a mouse. The media query takes one of three values:

  • none
    The device does not have any pointing device at all.
  • coarse
    The device has a pointing device with limited accuracy; for example, a mobile phone or tablet with touch capabilities, where the “pointer” would be a finger.
  • fine
    The device has an accurate pointing device, such as a mouse, trackpad or stylus.

Using this media query, we can enlarge buttons and links for touch devices:

@media  (pointer:coarse) {
   input[type="submit"],
       a.button {
       min-width: 30px;
       min-height: 40px;
       background: transparent;
   }
 }

The pointer media query is not yet supported and is merely being proposed. Nevertheless, the potential is huge because it would enable us to detect touch devices via CSS, without the need for a third-party library, such as Modernizr91.

CSS Level 4 “Hover” Media Query

The CSS Level 4 specification proposes a new hover media query92, which detects whether a device’s primary pointing system can hover. It returns a Boolean: 1 if the device supports hover, 0 if not. Note that it has nothing to do with the :hover pseudo-class.

Using the hover media query, we can enhance an interface to hide certain features for devices that do support hovering. The code would look something like this:

 @media  (hover) {
   .hovercontent { display: none; } /* Hide content only for devices with hover capabilities. */

   .hovercontent:hover { display: block; }    
 }

It can also be used to create dropdown menus on hover; and the fallback for mobile devices is in native CSS, without the need for a feature-detection framework.

CSS Level 4 Luminosity Media Query

Another capability of mobile devices is the luminosity sensor. The CSS Level 4 specification has a media query for luminosity93, which gives us access to a device’s light sensors directly in the CSS. Here is how the specification describes it:

“The “luminosity” media feature is used to query about the ambient luminosity in which the device is used, to allow the author to adjust style of the document in response.”

In the future, we will be able to create websites that respond to ambient luminosity. This will greatly improve user experiences. We will be able to detect, for example, exceptionally bright environments using the washed value, adapting the website’s contrast accordingly. The dim value is used for dim environments, such as at nighttime. The normal value is used when the luminosity level does not need any adjustment.

The code would look something like this:

 @media  (luminosity: washed) {
   p { background: white; color: black; font-size: 2em; }
 }

As you can see, CSS Level 4 promises a lot of fun new stuff. If you are curious to see what’s in store, not only mobile-related, then have a look at “Sneak Peek Into the Future: Selectors, Level 494.”

More Mobile Capabilities to Detect Using APIs and JavaScript

Many other things could be detected to make the user experience amazing on a responsive website. For example, we could gain access to the native gyroscope, compass and accelerometer to detect the device’s orientation using the HTML5 DeviceOrientationEvent95. Support for DeviceOrientationEvent96 in Android and iOS browsers is getting better, but the specification is still a draft. Nevertheless, the API look promising. Imagine playing full HTML5 games directly in the browser.

Another API that would be particularly useful for some mobile users is geolocation97. The good news is that it’s already well supported98. This API enables us to geolocate the user using GPS and to infer their location from network signals such as IP address, RFID, Wi-Fi and Bluetooth MAC addresses. This can be used on some responsive websites to provide users with contextual information. A big restaurant chain could enhance its mobile experience by showing the user the locations of restaurants in their area. The possibilities are endless.

The W3C also proposed a draft for a vibration API99. With it, the browser can provide tactile feedback to the user in the form of vibration. This, however, is creeping into the more specific field of Web applications and mobile games in the browser.

Another API that has been highly discussed is the network information API100. The possibility of measuring a user’s bandwidth and optimizing accordingly has seduced many developers. We would be able to serve high-quality images to users with high bandwidth and low-quality images to users with low bandwidth. With the bandwidth attribute of the network API, it would be possible to estimate the downloading bandwidth of a user in megabytes per second. The second attribute, metered, is a Boolean that tells us whether the user has a metered connection (such as from a prepaid card). These two attributes are currently accessible only via JavaScript.

Unfortunately, measuring a user’s connection is technically difficult, and a connection could change abruptly. A user could go into a tunnel and lose their connection, or their speed could suddenly drop. So, a magical media query that measures bandwidth looks hypothetical at the moment. Yoav Weiss has written a good article about the problems that such a media query would create and about bandwidth measurement, “Bandwidth Media Queries? We Don’t Need ’Em!101

Many other APIs deal with mobile capabilities. If you are interested in learning more, Mozilla has a very detailed list102. Most are not yet fully available or standardized, and most are intended more for Web applications than for responsive websites. Nevertheless, it’s a great overview of how large and complex mobile websites could get in future.

Rethinking The Way We And The User Deal With Content

From a technical perspective, there are still a lot of challenges in dealing with content at a global scale. The mobile-first method has been part of the development and design process for a little while now. We could, for example, serve to mobile devices the minimum data that is necessary, and then use JavaScript and AJAX to conditionally load more content and images for desktops and tablets. But to do this, we would also have to rethink how we deal with content and be able to prioritize in order to generate content that is flexible enough and adaptive. A good example of this is the responsive map solution described above: we load an image for mobile, and enhance the experience with a real map for desktops. The more responsive the website, the more complex dealing with content gets. Flexible code can help us to format adaptive content.

One way suggested by some people in the industry is to create responsive sentences by marking up sentences with a lot of spans that have classes, and then displaying certain ones according to screen size. Trimming parts of sentences for small devices is possible with media queries. You can see this technique in action on 37signals’ Signal vs. Noise103 blog and in Frankie Roberto’s article “Responsive Text104.” Even if such technique could be used to enhance small parts of a website, such as the footer slogan, applying it to all of the text on a website is hard to imagine.

This raises an issue in responsive Web design that will become more and more important in future: the importance of meta data and the semantic structure of content. As mentioned, the content on our websites does not only come from in-house writers. If we want to be able to automatically reuse content from other websites, then it has to be well structured and prepared for it. New HTML5 tags such as article and section are a good start to gaining some semantic meaning. The point is to think about and structure content so that a single item (say, a blog post) can be reused and displayed on different devices in different formats.

The big challenge will be to make meta data easily understandable to all of the people who are part of the content creation chain of the website. We’ll have to explain to them how the meta data can be used to prioritize content and be used to programmatically assemble content, while being platform-independent. A huge challenge will be to help them start thinking in terms of reusable blocks, rather than a big chunk of text that they copy and paste from Microsoft Word to their WYSIWYG content management system. We will have to help them understand that content and structure are two separate and independent things, just as when designers had to understand that content (HTML) and presentation (CSS) are best kept separate.

We can’t afford to write content that is oriented towards one only platform anymore. Who knows on which devices our content will be published in six months, or one year? We need to prepare our websites for the unexpected105. But to do so, we need better publishing tools, too. Karen McGrane gave a talk on “Adapting Ourselves to Adaptive Content106,” with some real example from the publishing industry. She speaks about the process of creating reusable content and introduces the idea of COPE: create once and publish everywhere. We need to build better CMSes, ones that can use and generate meta data to prioritize content. We need to explain to people how the system works and to think in terms of modular reusable content objects, instead of WYSIWYG pages. As McGrane says:

“You might be writing three different versions of that headline; you might be writing two different short summaries and you are attaching a couple of different images to it, different cut sizes, and then you may not be the person who is in charge of deciding what image or what headline gets displayed on that particular platform. That decision will be made by the metadata. It will be made by the business rules. […] Metadata is the new art direction.”

Truncating content for small devices is not a future-proof content strategy. We need CMSes that provide the structure needed to create such reusable content. We need better publishing workflows in CMSes, too. Clunky interfaces scare users, and most people who create content are not particularly comfortable with complicated tools. We will have to provide them with tools that are easy to understand and that help them publish clean, semantic content that is independent of presentation.

Conclusion

As long as this article is, it only scratches the surface. By now, most of Smashing Magazine’s readers understand that responsive Web design is much more than about throwing a bunch of media queries on the page, choosing the right breakpoints and doubling the size of images for those cool new high-density phones. As you can see, the path is long, and we are not there yet. There are still many unsolved issues, and the perfect responsive solution does not exist yet.

Some technical solutions might be discovered in future using some of the new technologies presented here and with the help of the W3C107, the WHATWG108 and organizations such as the Filament Group109.

More importantly, we Web designers and developers can help to find even better solutions. People such as Luke Wroblewski110 and Brad Frost111 and all of the amazing women and men mentioned in this article are experimenting with a lot of different techniques and solutions. Whether any succeeds or fails, the most important thing is to share what we — as designers, developers, content strategists and members of the Web design community — are doing to try to solve some of the challenges of responsive Web design. After all, we are all in the same boat, trying to make the Web a better place, aren’t we?

(al) (ea)

↑ Back to topShare on Twitter

Stéphanie is a French Graphic & Web Designer, Pixel & CSS lover, WordPress & coffee addict. She loves UI and UX design for mobile and web apps. She freelances and blogs at inpixelitrust, where she loves to share her knowledge, ideas and discoveries, as well as useful links, code snippets, plugins and the like. Stéphanie also publishes articles at Codrops, Onextrapixel and Noupe ( and in French at Alsacréations ). She also teaches courses on Mobile design and optimization, jQuery Mobile, and HTML & CSS for beginners at the University of Strasbourg.

  1. 1

    Oh man really lengthy but super great article. I’m excited for better responsive images. I feel like that’s such a fundamental upgrade that will effect everyone. Some of the other points may have smaller applications for users. I also love seeing which browsers support what features.

    14
  2. 3

    You guys fixed the iPhone size for SM (used to have horizontal scroll) – Nice!

    Couple of things: my personal favourite for menu icon is the “grid” but that is because how the menu on my site actually looks: a grid of images. Maybe though we should think a bit outside the box: menus look different and icons should look like they represent how the actual menu looks, but what about having a thick border and rounded edges to symbolize the importance and function of that button instead? This will give some flexibility for the designers to choose the right graphic. Just a thought.

    7
  3. 4

    Awesome, Waiting for the creditable CSS 4 Level Release. Nice to catch the user experience feel.

    0
  4. 5

    Yay, very nice overview of all “problems” that responsive web design has brought to us :)

    However, we could add that we might need better and “cleverer” browers : for example, a simple idea : every content that is hidden with a display: none or whatever should be not downloaded. Same with media-queries.

    Another idea : we could have easier CSS parameters that could allow us to defer loading of images, blocks, whatever. Even if JavaScript allows us to do this kind of loading, it could be great to have more and more power in CSS.

    Why not imagine :

    .foo {
      background-image(blablabla.jpg);
      loading: defer;
    }
    

    It is just an example of course.

    10
  5. 8

    Great article, I have started a new job so my first task is to make the site responsive. I have recently done a lot of research on different techniques and I came to a lot of the conclusions you have had. In this new environment we are going to target our largest markets for optimisation and then work on making nice for everyone else. It used to be which browsers do we target, now its what devices do we support. So I think I have been doing the same kind of optimisation but in different ways over the years. And from experience I don’t think there will be a perfect solution anytime soon. But at least the companies I have worked for now understand its not so profitable to do lots of optimisation for the 1% of the 30% of mobile users we get.

    2
  6. 9

    Perfect article!

    3
  7. 10

    I think the best icon is the so called “burger” icon. Facebook uses it, Gmail uses it, Youtube uses it… And it’s a really simple onel.

    21
    • 11

      I agree! Keep it simple. A lot of big websites are using the “burger” icon so a lot of users are familiar with it. And from usability point of view, don’t make me think!

      5
      • 12

        Perhaps this is just me, but I think the “burger” icon has a semantic quality, too. It’s reminiscent of ridges, like on the cap of a bottle, which invite gripping and opening. It looks very tactile to me, in a way that a plus or an unordered list can’t be. I always think of it as a “gripper” icon.

        3
    • 13

      I think it is important that it looks like the design of your app or website. It must be recognized by the user as a familiar item. Designing icons can be a pain in the ass but with the described vision on menu icons, I am convinced that with testing these ‘UI challenges’ it will give you the best result for your website or app despite of what has been used or not by the big boys like Facebook and Google.

      0
  8. 14

    Thorvald Neumann

    May 29, 2013 4:47 am

    Awesome article, Stéphanie. Thank you. :-)

    I am also looking forward to a viable solution for the current responsive image mess and I really hope *all* browsers will support the same functionality.

    1
  9. 15

    Thanks for the nice, relevant article. Bookmarked.

    1
  10. 16

    Great article,

    I’m glad you brought up the point about frames and 3rd Parties use of them. I find it very frustrating that I have little control over the styling of the Facebook widget. (among others)

    It would be great if comperes such as Vimeo and YouTube started to provide embed code using the tag.

    In regards to the menu icon for mobile devices my preference is to use the “burger” icon. ;)

    0
  11. 17

    Good article!

    Is there any CSS library that compiles all these tips ?

    4
  12. 18

    Kenneth Elliott

    May 29, 2013 5:15 am

    Skimmed over the article, but can definitely tell some thought was put into it. I will archive for future reading.

    3
  13. 19

    Regarding responsive images

    The two options under consideration are really not viable at all from my point of view and should be thrown under the bus. Who is going to crank out all those images and deal with all that markup? Even with a macro in PhotoShop to create the images, it’s too much. Firstly I would like to acknowledge Oscar Godson’s frank thoughts (http://oscargodson.com/posts/picturefill-needs-to-die.html) on this matter. I agree with him and taking direction from the sad compromise that is the tag is wrong wrong wrong.

    Secondly I would like to throw out a different potential solution. All the thought on this topic appears to be markup-centric. I realize this is generally the bias within this community, but those of us who work on the server-side of things as well see things quite differently. Why not let the browser and the server sort it out between themselves with minimal direction from the markup itself?

    Specifically:

    A single large version of the image is stored on the web server

    The server has the capability to manipulate (resize, compress, crop, etc.) dynamically. This could be accomplished natively (in updated versions of Apache and IIS) or via third-party component – as is currently possible. I’m not talking about the compression capabilities already in Apache, I’m talking about functionality that already exists in software like ImageGen for IIS – I imagine there is something similar for Apache.

    The mechanism for sending the right image down the pipe would simply be a matter of the server parsing all the relevant data in the request (http header), reading its own config files (as it currently does) and spitting out the correct image on the fly – optionally with minimal instructions found in the markup. The server could also save the specific image meaning any performance hit is a one-time affair – ImageGen does this now.

    All this functionality currently exists; it just needs to be formalized into a specification. Going this route would create a solution that would work for all including content creators who don’t touch markup. It would automate the mundane work of image generation and would minimize the amount of html bloat.

    Just my two cents…

    17
    • 20

      I could not agree more about the complexity of maintaining different images for the new picture / srcset HTML elements. As I said, we need better CMSs. I’m not a back-end developer, but I suppose you could have some scripts that would automagically resize the images to serve them the right size for the different picture/srcset options, right ? After all this is already the case for WordPress, you can define different image size, you only enter one, and the server takes care of the other ones.
      You mechanisms sounds great, again, I’ve no real knowledge in server side component. Nevertheless, how would you plan on providing the right image, aka, how do you know it’s an iPhone, a Galaxy Tab, or a desktop browser ? You write about “http header”, so I gues you tend for a “User-Agent sniffing” based solution ? It could work, of course, but updating an accurate list of User Agents that work for every device that will come on the market might be pretty time consuming. The iPhone devices are not such a problem, but if you look at Android, device manufacturer can change the User Agent of the embeded browser. So it’s pretty hard to have an accurate list of all device + browser that will actually work. So if you have any better solution to detect a mobile/tablet that sniffing the http header, I would love to hear about :)

      1
      • 21

        The real solution of the future (if we can call it that) is one where the client (browser) and server work together to get the job done. Would it entail changes to the HTTP protocol? Perhaps and so be it. Maybe that is where the spec change needs to happen. Browser vendors have been messing us about with bogus User Agent info since the days of the blink tag – for their own benefit. That dog don’t hunt no more.

        We need a real solution for the future where the client is self-aware and can (honestly) communicate its situation to the server to optimize communications between them. I’ll leave the specifics of the implementation to the boffins at CERN and the other overlords of the web, but here is some pseudo-code that suggests what I’m talking about:

        Client Request #1 – “I’m IE running on a laptop, on some flaky WIFI connection. My user has been jumping around pages and is probably just looking for some quick information – please keep it somewhat light Mr. Server. Oh, and by the way, at the risk of stating the obvious (as I am a traditional laptop and you already know that), I only really see the web in a more landscape aspect ratio.”

        Server’s Response – “Yeah no worries, I’ve got your back. A reduced-calorie page is coming your way, oh and btw, the enlightened owner of the site was dialed-in enough to set the ‘importanceOfImages’ setting in the config file to mediumLow, so things should be fast.”

        Client Request #2 – “Hi Mr. Server, I’m Safari running on iOS 9, on an iPad6 with Apple’s latest retina display so my pixel-density is seriously off-the-charts dude. I’m on a corporate LAN as well, so BEER ME!”

        Server’s Response – “Epic dude! That is a sweet ride – here comes the mother lode.”

        Client Request #3 – “I’m a BlackBerry and my suit (owner) is constantly fiddling with me. Bare bones Mr. Server if you please. That said, if my suit spends more than thirty seconds on the page, you can send a small image down the wire. Otherwise keep it crazy-lean. “

        Server’s Response – “Cool, he was here yesterday btw and the image has not changed since then, AND, as your intelligentCachingDirective has not changed, I’m not even going to bother sending the image down the pipe. I’ll assume you’ll grab it out of your cache – let me know otherwise. You BlackBerry guys should buy me lunch one day for all the bandwidth I’ve been saving you.”

        Client Request #4 – “Hey Server Dude, I’m a screen reader, so obviously images are useless to me and as you probably noticed, I have not asked you for them. That said, anything else you can do to make things better for me and strip out all the crap that your site’s owner does not even know they are shipping down the pipe would be much appreciated.”

        Server’s Response – “Always a pleasure to help you guys out. The markup on the page totally semantic btw, so you are golden.”

        Yes distilling all the permutations of the above into reality would be a big job and yes there would be a myriad of other things to deal with such as privacy and security, but there are lots of smart people out there who could codify this into a reality.

        Once something like this exists (being hopeful here!) the job of the UX designer would be to configure it (set and forget) as opposed to writing silly markup and cranking out duplicate images for eternity. Call me lazy, call me a dreamer…..

        8
        • 22

          I absolutely love the heck out of this comment and the scenarios – and they all make sense.

          You are right, it is a real job of work to make that a reality, and perhaps we only get there in incremental steps (which is how things are moving now), but I share your vision.

          0
    • 23

      I entirely agree with your (and Godson’s) view on dealing with images. The proposed new tags and cumbersome syntax proposed to the W3C seem to be fixes with limited applicability. Overloading the client with polyfills and Javascript is not satisfactory either.

      One aspect I particularly liked in the article is the part on CMS and the need for target-client-and-format-independent content with proper meta-information. This has been a sore point for many years (long before the responsive Web craze), and is perhaps the most important aspect to tackle in the medium-term.

      1
    • 24

      Though not ideal, I think the responsive image solution above works perfectly well in the interim and should not be ‘thrown under the bus’. Users do not care which method or technique you are using. All they care about is fast and responsive applications on whichever media type they happen to view your content on. Yes, the mark-up is not easy on the eye, but that’s our problem as developers and designers. The user doesn’t see mark-up.

      With regards to having to create different image sizes, there are many CMS’s that provide this functionality out of the box. You specify which image sizes you want, give it a single high res image, and viola. All you need to do in your mark-up is specify which size you want. No photoshop in sight.

      I think waiting for the perfect solution stunts innovation and holds the web back. Let’s keep moving!

      0
      • 25

        I hear you and agree with the notion of moving forward, but in this case, I don’t think many people who deal with content (outside this community) will make the effort and there are lots of people out there that deal with content. The proposed solutions might appear to be an easy fix to a motivated designer, but that does not make them right – nor is what I’ve suggested above for that matter. I just think we need something better and specs are like old luggage – hard to get rid of.

        Think about it this way – what if the rag-tag html5 rebel alliance never went toe to toe with the xhtml empire (I’m sure they are nice people in reality), and what if Steve Jobs never put a bullet in Flash? Realistically the xhtml 2.0 spec would still be a going concern and we would still spend time embedding swf files instead of riffing on all the cool stuff in css3 and html5, and basically making the web a better place. Winning ugly worked.

        0
    • 26

      As previously stated, server manipulated images as described already is a reality, it’s just a matter of implementing it to suit your application.

      The proposed specification (new tags for images) are useful NOT ONLY to serve low or high resolution images, but to change what image is show in a specific screen size (as described in the article).

      Unless you are working with AI, the machine is not smart enough to decide what PART OF THE IMAGE is useful and if it is VISIBLE, or even if displaying a small version of the image is enough, perhaps showing a totally diferent image might be the case. This addresses a CONTENT matter.

      Backend developers tend to think only in bytes and metrics, and that’s a good thing while working on the backend. When you come to the frontend, you are dealing with people, and that involves a whole different mindset (think marketing, psychology, target audience, usability, user experience…)

      0
  14. 27

    In case anyone is interested, I documented how to integrate Picturefill.js with WordPress to automatically convert post thumbnails into the element: http://www.toekneestuck.com/blog/2012/04/22/picturefill-js-wordpress/ There’s also a plugin readily available that does a lot more, but uses a customized version of Picturefill.js and also takes some liberty to add more image sizes for you (if you’re particular about these things): http://wordpress.org/plugins/picturefillwp/

    2
  15. 28

    David Sandoval

    May 29, 2013 7:13 am

    Thanks for the great article, this one’s a keeper and will definitely use it for future reference :)

    I’d personally like to have a one-size-fits-all solution for fluid layouts but there seems to be great solutions out there with pros and cons, which one would you guys recommend for a small to medium-size project? I’ve considered going with bootstrap or keeping it simple with flexbox but still can’t make up my mind :/

    Cheers from beautiful Mexico!

    0
  16. 29

    Great complete article. Thanks a lot

    I would go with the burger icon. The fact that Facebook uses it helps a lot..

    1
  17. 30

    A little lengthy indeed, but skimming through there is some great content, a lot of stuff I didn’t know about.

    I’m interested to see where the image compression would go, and don’t understand if Google has created a better compression than jpg, why does Firefox refuse to implement it into their browser. I have been using transparent png’s a lot lately, but their heavy – even crunching them down with tools like tinypng still result in compromising your page weight.

    Also has anyone built an entire site/framework using the flexbox model? If so, please share.

    2
  18. 31

    “The problem with these techniques is that the navigation remains at the top of the screen.” I think that’s an acceptable placement, especially with a “content first, navigation second” approach. To quote Tapworthy author Josh Clark, “navigation is the miserable last resort when the rest of the page has failed you.” Get controls out of the way and let users look at the content.

    Capturing touch events could be problematic as we move toward more touchscreen desktops. Plus, what about basic feature phones or phones with trackpads? They couldn’t be detected as phones using touch events. The lines are getting more and more blurred between devices, and we have yet to find a good solution.

    Agree that responsive design is far from perfect. If we can’t design for screen size and breakpoints (since they’re so arbitrary), then how do we design? Specifically for agencies that sort of separate UX, design, and development – what can designers do in lieu of wireframes and comps? Do we need to start coding too?

    2
    • 32

      I think that designing for content would be a great start. Placing breakpoints when the content gets hard to read for example might be a nice start. Of course this means that we either need a deep cooperation between designer, UX experts and the front developer. This as you mentionned can be hard to achieve in agencies that tend to outsource the final front-developement. I don’t have “the” perfect solution, responsive webdesign is something pretty new and young, but I guess that communication between people into a project might help a lot here to work togheter towards a common goal :)

      0
  19. 33

    Awesome article! Lengthy, but a treasure trove of references and options. Thanks, Stéphanie.

    1
  20. 34

    Great article. And oh by the way, burger icon ftw!

    1
  21. 35

    Great article Stéphanie. Oh and by the way, burger icon ftw!

    0
  22. 36

    Michael Histen

    May 29, 2013 9:44 am

    This is a great article — and it brings up some potential techniques I had not even heard of before (such as luminosity detection).

    There is one section I have to disagree with, however — the idea of writing multiple versions of content, changing headlines and copy, etc. This seems both impractical and just not great UX either. A big part of the “mobile first” push is the idea that forcing yourself to be clearer and more concise for mobile means that you’ve ended up creating better content for all formats. Similarly, we’ve seen how frequently people are looking at the same site on multiple devices, and how frustrating it can be when they see different content. On top of all that, having worked with so many larger companies, I know what an enormous struggle it can be just to get basic content management in place, and the idea of then training everyone involved to be writing multiple versions of everything complete with device-specific metadata is really infeasible. Seems like an insurmountable challenge for something that would not actually improve (and might actually degrade) the user experience.

    3
    • 37

      I kind of agree with you. I wanted to show what can be done in the http://37signals.com/svn/ but Frankly parsing the whole content with many HTML span code to display or hide it is not possible “in real life”. When I write about the need of writing content for multiple plateforms, I don’t necessarly mean re-writing for each plateform, that no the purpose of responsive webdesign. It’s more like writing it once, but smantically splitting if with meta tags so that the content has more meaning. The example of Karen Mac Grane quoted in the article goes beyond because she is speaking specically about one particular branch of the industry which is the publication branch that has very specifics needs in terms of content since they are basically selling content for people to read. This of course can’t be done on all websites, but the idea of giving content more sens using meta-data is something that has more en more importance, hence all the new HTML5 tags for example :)

      1
  23. 38

    Can we please all agree, that what-ever Icon we use for the “Show Menu” we call it the “Hamburger Icon”
    …at this point, calling it anything else, just won’t make sense.

    1
  24. 39

    tl;dr

    -13
  25. 41

    I use the burger icon, but still have problems with some less internet educated people not knowing what it is.

    2
  26. 42

    Great extensive article. My two cents regarding the menu icon: The list icon with bullets clearly makes the best option from my point of view. All the others don’t say enough visually or could be confused with other common actions. A plus sign could mean adding an element, a grid of boxes is frequently associated with photo galleries, and the three lines on their own just don’t represent anything clearly enough to be universal.

    I would say almost every user is going to know what a point-form list represents and visually it mimics the typical navigation element paired with an icon which can’t really be seen as anything other than a list of items.

    2
  27. 43

    Outstanding article.

    I was just over Sitepoint reading an article on the same subject. The author makes it appear that implementing RWD is such a simple task. Yet, Sitepoint still uses a fixed layout. Not that there’s anything wrong with a fixed layout, but evangelizing that RWD is such an obvious process and not facilitating its use on a principle site appears somewhat hypocritical.

    Smashing Magazine does a very good job with it fluid layout. Your article expresses, in a most honest manner, the issues surrounding RWD, at least for me. If you visit the newly revamped A List Apart (with a claim to be “for people who make websites”), you will see one of my biggest issues with the use of RWD: sacrificing the desktop for mobile, which equates to sacrificing usability and accessibility for a large demographic of users.

    When I read articles on RWD, I see a lot about APIs and other Javascript techniques. Should Progressive Enhancement (which I am fond of) be sacrificed for the latest and greatest? Are there actual RWD techniques that can alleviate the need to use JS?

    My thought is that RWD is suppose to make a website available, in its entirety, to the most users without having to code what is basically multiple sites. RWD may change how one uses a site, but not the experience. On the many sites I’ve visited (excluding Smashing Magazine), this is not the case for me.

    So, my final question has to be: Are there any RWD techniques currently brought together under one consensus that designers can use to have a clear foundation of the current technology that will facilitate the best RWD implementation for all types of sites?

    5
    • 44

      I’ve not been to alistapart in a long time… You inspired me to go back there. It’s /abysmal/.

      - The header image takes up 50% of my screen

      - The copy is jumbo-blind-man size – which makes it unreadably big unless I lean way back in my chair

      - There’s not even a menu bar

      I died a little inside…

      5
  28. 45

    Very thorough ! Great info!!

    2
  29. 46

    This is definitely the most comprehensive and exhausting article about the patient’s current condition that I’ve read so far. Thanks for that, Stéphanie, brilliant work!

    Just my 2 cents about the icon question: I’m using the “burger icon”, or – to be more precise – I’m mostly using the unicode symbol ≡ (&amp;#9776;), as it is pretty well supported across devices and platforms and doesn’t require anything special like images, icon fonts or whatever (of course, there might be some issues with this one as well …).

    Keep on the awesome work! :)

    5
    • 47

      “This is definitely the most comprehensive and exhausting article about the patient’s current condition that I’ve read so far” => Ow I never thought about using the medial metaphore, but that’s very nice way to say it :)

      2
  30. 48

    Thanks a lot for a detailed write up on a very important but not properly addressed topic. Most importantly all pieces are now in ONE PLACE.

    0
  31. 49

    Andreas Cichocki

    May 30, 2013 12:05 am

    Awesome article, shows so much stuff we are dealing in this days to make an app working :)

    1
  32. 50

    Hey, nice Article!

    But this Part: “With this technique, Jobsis cut the weight of the image by 75%.” is wrong. The weight of the image is cut by 25%

    1
  33. 51

    I also use the burger icon. We had a usability test of a mobile site with “normal” users and a lot of them didn’t know the burger icon and therefore did not use it and could not complete some of the tasks. I decided that for some target groups (especially older people) it is best to write “menu” instead of using the icon. I hope this is going to change soon and that everyone will know what hides behind the burger icon.

    Another solution is to display the menu options above the footer (the icon in the navigation bar remains), so that people who do not know the icon can still navigate to the relevant content.

    2
  34. 52

    I’m on my iphone reading this and as everyone has pointed out – this is a long article. On a mobile device the desire to get to the navigation/search at the top if the page is an issue – or then scrolling to the bottom of the page to leave a comment – it becomes a very laborious process. Gesture recognition on touch devices needs to be incorporated into mobile browsers. Even Safari doesn’t scroll quicker after repeated flicks as the music app does when scrolling through the music library.

    Another option may be to have hidden divs that reveal on an up flick or down flick that disappears after a short interval – kind of similar to the Facebook and Google+ apps.

    3
    • 53

      Yeah I kind of know, I had said this myself, and their are still so many things that I did not mention. Like the scrolling problem you just pointed out, it’s true that this is another issue on mobile. I’m kind of used to read long texts on ebooks, but you can “flip” the pages in those.
      I’m not sure that this would make sence on blogs where articles should usually be read from the top to the bottom to fully understand them, but on some websites that display lots of information from wich the user only need one or two, a summary may be a nice trick. I’m working on the UX of a client’s site who has some huge lists of courses they teach that are classified under sub-categories. For desktop we decided to add a summary at the top of the page that would link to each categoy with an anchor and I’m pretty sure this will be a time saver for mobile user as well.

      0
  35. 54

    Michael Korkaris

    May 30, 2013 3:38 am

    I guess one approach for responsive images, that I use in my work, is actually use a DIV instead. Set the background-image to the image you like and the background-size property to cover or contain (depending on what you want) and always serve the highest resolution available. For PhoneGap applications (where everything is stored locally) this is a life saver. Of course for web apps, another approach is necessary.

    1
  36. 55

    “a pixel ratio higher than 2″

    That’s not a ratio. At all.

    That’s an integer which by itself, means nothing.

    -2
  37. 58

    Nice article, my compliments. I do however have one general point of criticism, not specifically on this article, but on almost all RWD articles: the problem scope is often made way too small. RWD is not an answer to mobile website issues, it’s an answer to ANY device. The reason I say this is because 99% of all substance in RWD articles is basically about mobile web development. Making things smaller. I think that view is too limited.

    5
    • 59

      I totally agree with you on this point. But when you already wrote 21 A4 pages, you have to focus on one aspect ;) I think that currently it’s nevertheless harder to optimize for smaller screen size than it is for large TV screens. You don’t have the same problems of lack of space for example. Also bandwidth is less likely to be bad on TV screen, although you could argue that you can leave in a country where general bandwith is pretty bad too.

      1
  38. 60

    Joshua Bambrick

    May 30, 2013 4:22 am

    Regrading the navigation icons, I would use the three lines icon whenever the menu is a vertical list of text links (like facebook) and the grid icon where the menu consists of iconised links in a grid (like google apps). I think users get these the best and they give a visual clue as to what will be displayed. Using either the other way around, wouldn’t make sense to me. I’m not sure if I would personally recognise the ‘plus’ icon as a menu at all, so I doubt users would.

    3
  39. 61

    John Flickinger

    May 30, 2013 6:09 am

    Great article! It’s a little low-tech, but with responsive inline images I’ve been a fan of the width:100% height:auto method combined with putting it into a flexible container. It’s a simple solution that works well for desktop and mobile browsers. The downside is that it won’t feed out retina/high res images by default, but you can also set up something similar that will with CSS that will.

    2
  40. 62

    Shannon Mølhave

    May 30, 2013 7:04 am

    This is a great post, though it’s a little disappointing not to see responsive email mentioned. I was surprised to see that in two email campaigns we’ve sent out in the last two days mobile vs. desktop opens are 50.3% vs. 41% and 68% vs. 27.9%. Responsive emails are a pain, but important.

    3
    • 63

      Feww responsive emails is such a huge an passionnating topic that I think it would deserve it own article. With email, you totally change the rules, many CSS properties are supported, I won’t even speak about CSS3 and HTML5. You have to rely on old table hacks and you don’t only have to optimize for browser, but email clients. That’s a whole new world here. As I mentionned it’s just a (long) top of the iceberg ;)

      3
      • 64

        Shannon Mølhave

        May 31, 2013 8:46 am

        ‘Tis true, it is its own monster. I just want to get more web designers thinking about it and aware of the need to address it (as painful as it is). :)

        0
  41. 65

    The css3 template lay-out sounds very promising… thumbs up if you want it implemented.

    Burger icon FTW!

    1
  42. 66

    Now that was a bloody good read. Looking forward to being able to use CSS4 in the future!

    1
  43. 67

    Great wrap up of where we are today with responsive design! I will definitely be bookmarking this (as well as a bunch of those links) for future references.

    On the topic of what type of icon to use for navigation: I personally prefer either the UL icon or the 3-line icon. When using the off canvas navigation those are the only two that really make sense to me, as the nav is presented in a list-like format. Really, they’re all acceptable in a case-by-case basis, but if we’re trying to establish the go-to icon, there should be some research into what types of navigation are used the most when going responsive. From what I’ve seen, the list-like format seems to be used the most.

    1
  44. 68

    Excellent article! I am in the process of going to class for website design and I do believe I have found my calling, even at almost 40 years old I can still hang with the younger ones in class. http://rudemom.com/

    -1
  45. 69

    Great wrap-up, but I do have a minor nit to pick.

    > Font icons are another growing trend. They involve using a font in which alphanumeric characters are replaced by icon glyphs…

    The alphanumerics don’t need to be replaced at all: many icon font generators will assign your glyphs to the Unicode private use areas. Icon fonts provide a way of adding useful pictographs to fonts and you don’t have to replace the useful alphanumeric characters to do it. Icon fonts are not a hack; and they need not be bastardised fonts (like Wingdings).

    I’ve seen far too many devs write off icon fonts as being a passing fad in the same line as CSS hacks because the technique has been misrepresented to them.

    2
  46. 70

    “As long as this article is”

    …it makes War and Peace look like a little light reading……..Geeeeeeeeezzzzzzz….! There may have been something good in there, but it’s totally lost in the bloated wordiness.

    -4
    • 71

      Yep, but as you see, the subjet of responsive webdesign is so complex that it’s pretty hard to write a short article. Also note that English is not my mother tongue, so if you have advices to make the sentences less “bloated wordiness” I would totally take them :)

      5
  47. 72

    Easily accessibly screen parts also kinda depends on whether you are right- or lefthanded…

    And for some reason I am yet to find a ‘lefthanded’ setting in iOS or Android…

    0
  48. 73

    Really enjoyed this article.

    0
  49. 74

    Good Day! Ums months ago I used the one theme that my client gave me, it had a map on the contact area, was only put it inside a div thumbnail (already in Bootstrap) and worked well, got better when the site is viewed mobile phone where it is possible to catch the customer’s location and plot a route to the company.

    0
  50. 75

    Wow thank you… A long but excellent Friday afternoon read that has given me a lot to ponder this weekend as I play with my portfolio.

    0
  51. 76

    I like the point about having the nav on the bottom so it’s easier for users on mobile and tablet devices. I may implement that and see the response I get from users.
    Not a fan of having different images for different devices unless the creation/duplication of images is automated somehow.
    Great article!

    0
  52. 77

    I’ve been getting more and more excited by the evolution of responsive. It’s had a rapid growth over the past couple years, and I think it’s mainly due to the developer community that pumps out innovative ways to make it more efficient on a (seemingly) daily basis. Kudos to all who practice and post tutorials.

    2
  53. 78

    I think I’ve read something like 2013 is the year of responsive web design.. but I wonder, just what percentage of businesses out there are really implementing this as it can be a costly option. I never thought of this issue about resolution and it’s great that you brought it up. I guess, we’re closer to that seamless user experience that will make everyone happy.. aren’t we?

    0
  54. 79

    I agree that we need to choose a standard icon to represent the navigation menu. In the meantime something that we do on our site is to simply put the word “menu” next to the icon. There’s plenty of space for it and it will help people understand what the icon means. Ex: http://confabevents.com

    0
  55. 80

    I use the burger icon. I find the other icons serve different uses.

    The [+] icon is so tough to use because different websites utilize it in vastly different ways so users never really know how that icon is going to behave.

    0
  56. 81

    Oh yeah, I just enjoyed the article and comments ofcourse :)

    0
  57. 82

    Wonderful article, very informative and concise.
    CSS Level 4 something new for me, will go deeper into it.

    P.S. It’s getting harder and harder to develop a single website and make it compatible with different desktop/mobile/tablet browsers.

    The hell of web design has started;)

    0
  58. 83

    Aashish Dhiman

    June 2, 2013 9:17 am

    so great

    0
  59. 84

    nice article. definitely going to follow these tips/points to optimize my website and to make it responsive.

    0
  60. 85

    Great Article, the final little tweaks i needed for developing responsive websites. Though i have a question for you to answer.

    Regarding a word press website, a user normally upload a single image to it post / page, as far as i aware of there is no way around it to supply different crops of images. On a bespoke website if we were to maintain it then great. What would your advice be on this?

    The way i done it as the moment is resize the image to the full width of the mobile device and left the height as auto. And for the default and standard icons, which are been upload twice one for normal resolution and the other for HD, which can be change in the stylesheet for the different devices.

    0
  61. 86

    Natasha Norton

    June 3, 2013 3:31 am

    I liked this article, and was particularly interested to read about images (loving pixel precision) and the formatting of content. Thank you :)

    0
  62. 87

    Great article although long, like you say- this really does only scratch the surface of responsive web design.

    With regards to the desired generalised choice of navigation icon I would have to go with the burger. More straight forward, aesthetically more pleasing imo and more recognisable I believe as menu icon.

    0
  63. 88

    “With this technique, Jobsis cut the weight of the image by 75%”
    Grammar nazi here. He cut it down TO 75% or BY 25%…. 21 kb -> 16 kb is a 25% drop

    1
  64. 89

    The whole concept of Responsive Design was created to give the user the best experience for the device they’re using. http://premiumresponsivewordpressthemes.blogspot.com/2013/06/wordpress-resposive-design.html

    -2
  65. 90

    Great info!!! Thank you for this.

    1
  66. 91

    Marcellino Bommezijn

    June 6, 2013 11:22 pm

    Very nice article indeed!

    When it comes to images, there are also some pretty nice server-side solutions. We use ASP.NET as main language and there is a nice little script that creates cached images of your larger image using a rewrite rule. It serves the appropiate image based on the current resolution of the device.

    Image Adaptivezr.NET
    http://codecanyon.net/item/image-adaptivezrnet/2024112?sso?WT.ac=search_item&WT.seg_1=search_item&WT.z_author=GreenTreeLabs

    1
  67. 92

    Patrick H. Lauke

    June 7, 2013 3:11 am

    Great, exhaustive overview. Two small points though:

    - on “detecting touch capabilities with native javascript”: yes, although it’s admittedly exotic to pair a mouse with a mobile/tablet device, there’s now a whole new class of affordable laptops (like the majority of the Win8 ones) and not so affordable ones (Chromebook Pixel) that are ostensibly “desktop” machines but have both touch and traditional mouse/trackpad/keyboard. So it’s important not to make a mistake of thinking these are always either/or. So your interface may need / can provide both :hover/:focus based elements, as well as providing alternatives for touch (long-press context menus, swipe interactions, etc). “In the future, we will be able to catch events ” the future’s already here. The W3C working group may be young, but their work is mostly retrospective, standardising what most browsers already have right now. See https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/

    - on “CSS Level 4 Pointer Media Query” note that currently, browsers will react to the least-capable pointer device. So, on a device that has both mouse AND a touchscreen, they’ll react to pointer:coarse regardless of whether or not the user is currently using one or the other input modality. There is some discussion about making browsers decide what the *primary* input mechanism is and use that instead, but quick: on a Win8 laptop with touch and trackpad, what’s the *primary* ? No peeking…the answer is undefined. See http://www.stucox.com/blog/the-good-and-bad-of-level-4-media-queries/ and http://www.stucox.com/blog/you-cant-detect-a-touchscreen/

    1
  68. 93

    Goncalo Borrega

    June 7, 2013 11:01 pm

    Awesome article. Good job!

    0
  69. 94

    WOW! That was a quite an interesting read. Though it could be quite overwhelming for a newcommer like me (less than a year in the field) The knowledge needed is getting broader as the days go by. Though, I’m passionate about it.
    The thing is, it is difficult to figure out what direction or tools to use nowadays.
    It seemed so much simpler 2 years ago when I started my web development course. I guess I wasn’t aware of the ride I was getting into back then.
    Still, it is exciting to see how it all evolves, kinda similar to how music recording techniques evolved back in the day of The Beatles and behond.

    Salutations cousine de la langue française.

    1
  70. 95

    in respect to the Icon’s for Phone menu problem,,, I PERSONALY see the + sign meaning I can add something,,,, the grid makes me think it will take me to my APPs,,,,,, the BULLET LIST is the One I would pick thinking it was a menu,,,,,,, the burger makes me think of the OPTIONs that most browsers are using now…..
    So MY vote would go to the BULLET LIST icon….

    nice article,, I learned a lot…. thank you…

    1
  71. 96

    “List” icon.

    0
  72. 97

    Hi Stephanie, Awesome article.
    Your conclusion that this article only scratches the surface really conveys the depth of the topic.
    I have registered for a webinar on Best practices in Responsive Web Design, it looks a promising one. Don’t forget to register here: http://j.mp/125MSXv

    2
  73. 98

    Un EXCELLENT article !

    Ce n’est pas la première fois que je tombe sur de très bonnes ressources web et q’une fois arrivé en bas de l’article je découvre cette jolie photo d’une jeune fille un mug moustache à la bouche (Codrops, Alsacréation, Smashing…).

    Mademoiselle Walter vous déchirez !

    Merci pour tout !

    0
    • 99

      I will reply in English since it’s the language of this blog and that non French speaking people might want to understand something.
      It’s always cool to get constructive feedbacks so I’m really glad you enjoy my articles on the web, thanks a lot :)
      Nevertheless, note that the avatar of a cute young girl is 100% Photoshoped and that I’m a dude with a huge mustach in real life (yeah no girls on the internet, remember? ) But I’m sure you’ll enjoy my articles anyway knowing that :p
      Final note, Alsacréations has an S at the end (http://www.alsacreation.com/ ) :) I point this out because my bosses tend to get angry when people forget the S and start killing kitten so it might get messy :(

      Cheers :)

      1
      • 100

        You know how French People are, so proud to speak in the language of Francis Lalanne (and Molière incidentally).

        Regarding your avatar they have already done this to me, an avatar of a woman, who said that in reality she is a man and ultimately turns out to be a cat.
        I won’t let that happen to me again !

        About my forgetfulness: http://preview.tinyurl.com/nwxlaes Shame on me !

        More seriously, I really thank you for this article (and its French translation on Alsacréations).
        I recently started working in a Toulousaine web agency and I really want to do the “good” RWD.
        This is not an easy task but it is this kind of article that makes us a reflection, a support and an early solution to build the “adaptive” web of tomorrow.

        Cheers :)

        1
  74. 101

    Nice article, took a while to read all of it though. ;)

    One of my recent struggles with responsive design has come in the form of complex apps and widgets. Take for example an image Gallery, now for Desktop I’d want that to be more complex and use buttons on the screen. However on mobile and some tablet devices I want it to be far simpler and use swipe gestures. What would be amazing is if you could detect what device type the user is on server side using say PHP. You would then be able to include the appropriate code based on that information.

    0
    • 102

      There is a solution for letting the server know what the client knows. It’s called RESS and was described by Luke W http://www.lukew.com/ff/entry.asp?1392. A simple implementation is provided by the Detector project by D.M.Olsen http://detector.dmolsen.com. This requires an initial request that runs Modernizr to find the browser capabilities and then sends them to the server. If the server is only interested in device capabilities it can cache this and use the user agent string as a key. If runtime capabilities are needed those can be obtained on every request except the first.

      0
  75. 103

    Very informative and insightful about responsive web design, Stéphanie. There’s so much to learn about responsive web design…we’re just beginning to scratch the surface ourselves over here in our small web design shop in Dallas, TX. Thanks for sharing your tips and knowledge.

    1
  76. 104

    Great info it is totally worth it, Yes this is the Era of Responsive Design, if you are not considering it, you will be left behind. These days, people spend a lot of time reading and surfing the internet from their Tablets and Phones.

    0
  77. 105

    Thank you for the excellent article. No, let me correct that with excellent tutorial:)

    Very good information that has gained you a new follower and respect Stéphanie.

    Terry

    0
  78. 106

    and, about menu icons in mobile, the best for me is the “list icon menu”

    0
  79. 107

    My partner found this blog and she said it was very informative and I should read it. A very knowledgeable piece..

    0
  80. 108

    “No one can deny your great efforts in passing this important information, I tried it also and it really helps but I would to add just more few tips , if you don’t mind for sure.
    what could take for Designing well done responsive website
    Don’t hide anything just keep your website comfortable for mobile users to read easily but keep in your mind that Google prefer good contents only.

    Best Regards,

    Pillar Jo
    http://www.smarttouch.me

    0
  81. 109

    Hi Stéphanie
    thanks for this tut
    Im a beginer to lrearn html & css and really like responsive design
    I beg you to Introduction a best sourc tut me as a beginer
    the sourc that Explain code In simple words
    with best regard and
    thanks

    0
    • 110

      Hi there,
      رها If you want, make a look at http://twittstrap.com you find everything a developer hopes to find for these projects. You can download twittstrap (Flat Version of Bootstrap) from http://twittstrap.com/twittstrap to start your projects. You can also find documentation to properly use twittstrap.
      – twittstrap also has two extra : Form Builder and Snippets for faster and easier web development.
      Greeting

      0
  82. 111

    Amazing article, thanks Stéphanie!

    0
  83. 112

    Here I am in October reading your article… proves the value in your work. Thank you Stéphanie for all the insight. And thanks to your fans for filling in the holes.

    I’m new to the RWD, so I am a sponge for all the good info.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top