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)

Footnotes

  1. 1 http://responsiveimages.org/
  2. 2 http://picture.responsiveimages.org/
  3. 3 http://usecases.responsiveimages.org/#art-direction
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2013/05/pictureelement_mini.jpg
  5. 5 http://www.flickr.com/photos/egorick/3754608666/
  6. 6 http://www.w3.org/community/respimg/
  7. 7 https://github.com/scottjehl/picturefill
  8. 8 http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
  9. 9 http://dev.w3.org/csswg/css4-images/#image-set-notation
  10. 10 https://developers.google.com/speed/webp/
  11. 11 http://www.google.com/chromeframe?quickenable=true
  12. 12 http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/
  13. 13 http://blog.netvlies.nl/design-interactie/retina-revolution/
  14. 14 http://www.smashingmagazine.com/wp-content/uploads/2013/05/imagecompression_mini1.jpg
  15. 15 http://www.smashingmagazine.com/2012/01/16/resolution-independence-with-svg/
  16. 16 http://css-tricks.com/using-fonts-for-icons/
  17. 17 http://www.w3.org/TR/css3-flexbox/
  18. 18 http://caniuse.com/#feat=flexbox
  19. 19 http://www.smashingmagazine.com/wp-content/uploads/2013/05/flexbox_mini1.jpg
  20. 20 http://www.smashingmagazine.com/2011/09/19/css3-flexible-box-layout-explained/
  21. 21 https://github.com/edenspiekermann/minwidth-relocate
  22. 22 http://www.w3.org/TR/css3-multicol/
  23. 23 http://www.smashingmagazine.com/wp-content/uploads/2013/05/responsicecolumns_mini1.jpg
  24. 24 http://davidwalsh.name/css-columns
  25. 25 http://dev.w3.org/csswg/css3-grid-layout/
  26. 26 http://www.w3.org/TR/css3-grid-layout/#grid-definition-columns
  27. 27 http://caniuse.com/#feat=css-grid
  28. 28 http://24ways.org/2012/css3-grid-layout/
  29. 29 http://www.rachelandrew.co.uk/archives/2013/04/10/css-grid-layout---what-has-changed/
  30. 30 http://www.w3.org/TR/2009/WD-css3-layout-20090402/
  31. 31 http://www.smashingmagazine.com/wp-content/uploads/2013/05/templatelayout_mini1.jpg
  32. 32 http://code.google.com/p/css-template-layout/
  33. 33 http://www.w3.org/TR/css3-values/#viewport-relative-lengths
  34. 34 http://caniuse.com/#feat=viewport-units
  35. 35 http://www.w3.org/TR/css3-values/#font-relative-lengths
  36. 36 http://caniuse.com/#search=rem
  37. 37 http://techtime.getharvest.com/blog/in-defense-of-rem-units
  38. 38 http://www.smashingmagazine.com/2010/03/11/forms-on-mobile-devices-modern-solutions/
  39. 39 http://www.w3.org/wiki/HTML5_form_additions#required
  40. 40 http://caniuse.com/#search=required
  41. 41 http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#the-autocomplete-attribute
  42. 42 http://www.w3.org/wiki/HTML5_form_additions#New_form_controls
  43. 43 http://www.smashingmagazine.com/wp-content/uploads/2013/05/datepicker-jquery_mini2.jpg
  44. 44 http://www.w3.org/TR/html-markup/input.date.html#input.date
  45. 45 http://www.w3.org/TR/html-markup/input.datetime.html#input.datetime
  46. 46 http://www.smashingmagazine.com/wp-content/uploads/2013/05/mobile-input-type-date_mini1.jpg
  47. 47 http://caniuse.com/input-datetime
  48. 48 http://demo.mobiscroll.com/calendar/calendartime
  49. 49 http://www.lukew.com/ff/entry.asp?1653
  50. 50 http://www.lukew.com/ff/entry.asp?756
  51. 51 http://filamentgroup.com/lab/responsive_design_approach_for_complex_multicolumn_data_tables/
  52. 52 http://filamentgroup.com/examples/rwd-table-patterns/
  53. 53 http://jquerymobile.com/branches/tables/docs/tables/table-column-toggle.html
  54. 54 http://www.smashingmagazine.com/wp-content/uploads/2013/05/responsivedatable01_mini1.jpg
  55. 55 http://dbushell.com/2012/01/05/responsive-tables-2/
  56. 56 http://www.zurb.com/playground/responsive-tables
  57. 57 http://www.smashingmagazine.com/wp-content/uploads/2013/05/responsivetable02_mini1.jpg
  58. 58 http://jquerymobile.com/branches/tables/docs/tables/table-reflow.html
  59. 59 http://css-tricks.com/responsive-data-tables/
  60. 60 http://www.smashingmagazine.com/wp-content/uploads/2013/05/responsivetable03_mini1.jpg
  61. 61 http://css-tricks.com/responsive-data-table-roundup/
  62. 62 http://www.tjkdesign.com/
  63. 63 http://alistapart.com/article/creating-intrinsic-ratios-for-video
  64. 64 http://amobil.se/2011/11/responsive-embeds/
  65. 65 http://www.w3.org/wiki/HTML/Elements/video
  66. 66 http://caniuse.com/#feat=video
  67. 67 http://fitvidsjs.com/
  68. 68 https://developers.google.com/maps/mobile-apps
  69. 69 https://developers.google.com/maps/documentation/staticmaps/
  70. 70 http://bradfrostweb.com/blog/post/adaptive-maps/
  71. 71 http://css-tricks.com/convert-menu-to-dropdown/
  72. 72 http://uxmovement.com/forms/stop-misusing-select-menus/
  73. 73 http://bradfrostweb.com/blog/web/responsive-nav-patterns/
  74. 74 http://bradfrost.github.com/this-is-responsive/patterns.html#navigation
  75. 75 http://www.smashingmagazine.com/2013/01/15/off-canvas-navigation-for-responsive-website/
  76. 76 http://www.smashingmagazine.com/wp-content/uploads/2013/05/navigations-mobile_mini1.jpg
  77. 77 http://www.lukew.com/ff/entry.asp?1649
  78. 78 http://www.smashingmagazine.com/wp-content/uploads/2013/05/touchaccess_mini.jpg
  79. 79 http://www.lukew.com/ff/entry.asp?1649
  80. 80 http://jasonweaver.name/lab/touchnav/v2/
  81. 81 http://codepen.io/bradfrost/full/mlyvu
  82. 82 http://codepen.io/bradfrost/full/orJwL
  83. 83 http://codepen.io/bradfrost/full/vcuem
  84. 84 http://codepen.io/bradfrost/full/qwJvF
  85. 85 http://www.smashingmagazine.com/wp-content/uploads/2013/05/navigationicons_mini.jpg
  86. 86 http://stuffandnonsense.co.uk/blog/about/we_need_a_standard_show_navigation_icon_for_responsive_web_design
  87. 87 http://www.w3.org/TR/touch-events/
  88. 88 http://eightmedia.github.com/hammer.js/
  89. 89 http://jgestures.codeplex.com/
  90. 90 http://dev.w3.org/csswg/mediaqueries4/#pointer
  91. 91 http://modernizr.com/docs/#touch
  92. 92 http://dev.w3.org/csswg/mediaqueries4/#hover
  93. 93 http://dev.w3.org/csswg/mediaqueries4/#luminosity
  94. 94 http://www.smashingmagazine.com/2013/01/21/sneak-peek-future-selectors-level-4/
  95. 95 http://dev.w3.org/geo/api/spec-source-orientation.html#deviceorientation
  96. 96 http://caniuse.com/#feat=deviceorientation
  97. 97 http://dev.w3.org/geo/api/spec-source.html
  98. 98 http://caniuse.com/#search=geolocation
  99. 99 http://dev.w3.org/2009/dap/vibration/
  100. 100 http://www.w3.org/TR/netinfo-api/
  101. 101 http://www.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-dont-need-em/%22
  102. 102 https://wiki.mozilla.org/WebAPI
  103. 103 http://37signals.com/svn/
  104. 104 http://www.frankieroberto.com/responsive_text
  105. 105 http://www.smashingmagazine.com/2013/01/14/preparing-websites-for-the-unexpected/
  106. 106 http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-adaptive-content-video-slides-and-transcript-oh-my/
  107. 107 http://www.w3.org/
  108. 108 http://www.whatwg.org/
  109. 109 http://filamentgroup.com/
  110. 110 http://www.lukew.com
  111. 111 http://bradfrostweb.com/

↑ Back to top Tweet itShare on Facebook

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.

Advertising
  1. 1

    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
  2. 52

    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
  3. 103

    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
  4. 154

    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
  5. 205

    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
  6. 256

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

    0
  7. 307

    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
  8. 358

    Aashish Dhiman

    June 2, 2013 9:17 am

    so great

    0
  9. 409

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

    0
  10. 460

    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
  11. 511

    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
  12. 562

    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
  13. 613

    “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
  14. 664

    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
  15. 715

    Great info!!! Thank you for this.

    1
  16. 766

    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
  17. 817

    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
  18. 868

    Goncalo Borrega

    June 7, 2013 11:01 pm

    Awesome article. Good job!

    0
  19. 919

    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
  20. 970

    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
  21. 1021

    “List” icon.

    0
  22. 1072

    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
  23. 1123

    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.

    1
    • 1174

      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.

      -1
  24. 1225

    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
    • 1276

      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
      • 1327

        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 :)

        0
  25. 1378

    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
  26. 1429

    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
  27. 1480

    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
  28. 1531

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

    0
  29. 1582

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

    0
  30. 1633

    “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
  31. 1684

    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
    • 1735

      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
  32. 1786

    Amazing article, thanks Stéphanie!

    0
  33. 1837

    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
  34. 1888

    This was a great article and will definitely help me present the idea of relying on css for more of what we do within the company I work for.

    I also wanted to add that we use the “burger” icon, or “bars”, for mobile menus; however, it gets placed in the upper left. Point is, I feel that the bars, or burger, screams menu. The ul-like icon tells me it’s a list. The grid is used by mobile devs and sites designed to give similar experiences across devices for apps, or the app drawer. The plus sign for me signifies that “yes, there’s something more and you need to tap that button right there to see it,” but is that content important to my navigation? I have no idea. Why waste someone’s time like that?

    I vote mobile/device navigation, or any sort of toggled navigation/menu for that matter, should utilize the “burger bars” icon.

    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