How many times have you created web pages only to find that a viewer complains that they look poor on a mobile device? I'll bet that one possible reason for this is image content. The image is set with fixed sizes, so it doesn't resize well in smaller browsers, right?

In this tutorial, we will take a look at the basics needed to move away from fixed images to those that adapt when a browser window has been resized or content is being viewed on a mobile device.

For this exercise, I've created a dummy page about Lake Peyto in Canada—a truly stunning part of Canada if you are fortunate to be able to visit! Throughout this tutorial, we're going to make some changes to help make the image react better when resized in a browser window. These steps will guide you through the exercise:

If all is well when resizing the image, the content will adjust but remain within the confines of the #peytoe div, as shown in this screenshot:

It should be noted that this approach may not work for all sites. For example, it may be preferable to crop it first using the background position before scaling it down to a smaller size. It will depend on your design as well as the type and quantity of images used; this is something that needs to be considered during design.

Now that we've seen the basics of making images responsive, let's move on and take a look at how we can improve on this by using higher quality images on supported devices. Before we do this though, it is worth covering a couple of key points about responsive design, namely relating to the use of vendor prefixes and image formats.

We'll start this section with a question. Hands up if you thought that creating responsive content requires special image formats or lots of vendor prefixes? If you think yes is the answer, then think again—two to three years ago, you may have had to work with something like the following lines of code as an example media query:

@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (-o-device-pixel-ratio: 3/2), 
only screen and (min-device-pixel-ratio: 1.5) {
    /* High-res version of image assets go here */
}

Now, all you need to cater to most modern browsers (that is, versions released within the last 12 to 18 months) is this—not a vendor prefix in sight:

(min-resolution: 192dpi) { 
    /* CSS styles here */
}

A similar principle applies for images—there is no need for a special format that needs to be used solely for media queries, or a need to use lots of different formats to cater to different devices. We only need to choose one format—any format will work. The exception here is that while using PNG or JPG images will produce results, you will find that the quality will begin to suffer in some instances as these formats do not scale up well.

Instead, it is better to use the SVG format when working responsively. This is effectively XML, which can be edited using tools such as Inkscape or Illustrator; it even can be edited in a text editor! The key to using SVG though is that it scales perfectly; irrespective of the size of the browser window, the image quality will be unaffected. It's an ideal format for logos, patterns, icons, and so on, but not for photographs, where the lossy format will not scale well.

At this point, you may hopefully be asking yourself, "What about mobile devices?"—it's a good question after all: the whole point of responsive design is to cater to mobile devices! Most of the tips and tricks we will encounter throughout this chapter will work on a mobile platform, although there are some useful guidelines that are worth noting:

Now that the theory is out of the way, let's get coding! We're going to begin with one of the key elements of working with responsive media—catering to high-resolution (hi-res) or retina-based images.

How often have you used a mobile device, such as an iPad, only to find images of poor quality? With the advent of retina displays on devices such as iPads, it is becoming more important to ensure your images are of sufficient quality on high-resolution screens.

Retina display is a proprietary marketing term coined by Apple, rather than a scientific term. To some it might evoke images of a complex scientific process; in reality it is just double resolution where pixels have been very closely packed to give higher quality and resolution. As an example, the pixel count can be anywhere from 220 pixels per inch (PPI) for third generation Mac Book Pros to 401 PPI for iPhone 6 Plus!

Adding retina support to our code is easy. There are several options open to us:

We can always set our code to display high-resolution images; however, there is a cost in displaying these images in the form of a bigger file size; the quality will be lost on low-resolution (low-res) devices.

Instead, we could use a plugin, such as Retina JS, to tell browsers to serve hi-res images only when needed. Let's take a look at using one in action:

To preview the results, it is recommended to use Google Chrome. We can easily simulate changing the device pixel ratio setting; change it from 1 to 2 and refresh the screen to see the change from the low-res image to the one of higher quality. We will cover how to create media queries that support hi-res images later in this chapter in the Working out media queries section.

So far, our examples all have something in common: they work with individual images. This is fine for those that may only appear once or twice at the most, but what if they appear frequently throughout your site? It seems pointless to have to call them each time. Fortunately, we can get around this with the use of image sprites.

For the uninitiated, image sprites are a way of combining lots of (ideally, small) images into one larger one then using CSS style rules to display the relevant part of that image. We typically might use background-position to position the image; using values in pixels, this works perfectly well. We can use the same principle with responsive sprites but with one key difference: we use percentage values instead, not pixels! Let's take a look at how to do it using some battery icons as an example:

However, there are some drawbacks that we need to be aware of when using this approach:

To see how awkward it is and to see the resulting changes in code required to remove the use of data URIs from the HTML markup, take a look at imagesprites2.html and imagesprites2.css in the code download that accompanies this book. Notice how the CSS has significantly changed.

Let's change tack—a key concept of responsive design is to determine the available viewport we can use when displaying content. Let's see what this means, when working with images.

Viewport? Surely you mean screen estate or perhaps resolution? In this instance, no. When designing responsively, we have to cater to screens of all different shapes and sizes; it's not enough to simply design for a certain screen resolution. Instead, we have to allow for the fact that the available space in a browser window (or viewport) might be smaller; we have to design our breakpoints to fit this available space.

A good reference point to see the available viewport on a host of devices is http://viewportsizes.com/ and then navigating to http://viewportsizes.com/mine/. This will display the current space available to us. There are two ways to set the available viewport for use: one using CSS/HTML markup and the other using jQuery or JavaScript. We'll take a look at using the CSS method first.

Using CSS to set our viewport

This is probably one of the simplest settings to add to any responsive design, yet it has the potential to open up a hornet's nest of problems! Setting the viewport using CSS is a one-line piece of code; the difficulty is in working out the CSS styling needed to position the elements correctly once the viewport has been set.

Tip

For this demo, it is recommended that you use Google Chrome. It has a built-in device emulation facility that makes it easy to test our results in different viewports. I will assume for the purposes of this demo that you have it installed.

We'll begin with setting the markup first, so we can at least see what happens when the viewport has not been set in CSS:

1. We'll start, as always, by preparing our markup. From the code download, extract the files: viewport-css.html, viewport-css.css, and pixel-grid.png; save them into the css subfolder and img subfolder respectively.
2. We've used the PT Sans font for decorative purposes. This is available from http://www.fontsquirrel.com/fonts/PT-Sans; you will need to download it and extract the fonts into a fonts subfolder within your project area.
3. Open Google Chrome and set the Emulation facility to emulate the Sony Xperia S, Ion devices, within the Developer Toolbar.

At this point, it is worth previewing the results in a browser; if all is well, we should see a result similar to this screenshot:

The keen-eyed among you will have noticed that something is clearly amiss. Our screen has not resized properly and text is being chopped off the right edge of the window. Let's fix that now using the following steps:

1. In viewport-css.html, add the following line as indicated:

     <title>Demo - Setting a viewport using CSS</title>
     <meta name="viewport" content="width=360">
     <link href="css/viewport-css.css" rel="stylesheet">

2. Resave the file and then refresh the screen in Chrome. If all is well, we can now see the results of our change with the text correctly sized and no overlap:
   

In this example, we've used <meta name="viewport" content="width=360">, which sets a very specific width of 360 px. For a more general setting where no specific width is used <meta name="viewport" content="width=device-width, initial-scale=1"> can be set instead.

When using media queries, we can always set the size of elements within our query. It's worth setting the viewport too so that items don't disappear off the page when resizing the browser window.

Note

For a good discussion on using the viewport meta tag, it is worth checking out an article by Paul Underwood, which is available at http://www.paulund.co.uk/understanding-the-viewport-meta-tag.

Now that we've worked out how much space we have to work with, we can now work out what happens to elements when we hit the limits of our available space. This is particularly relevant if we want to display hi-res images for example. After all, we don't want to show a high quality image if it chokes the available bandwidth of our device!

Let's take a look at how we can use media queries to switch between lo-res and hi-res versions of a single image:

At this point, we can use this trick to display any hi-res image we need; the key is to ensure we have two images, one of a standard resolution, while the other is of a higher quality. A small word of note though—if you spend any time researching different types of media queries, then you may come across something akin to these lines of code:

@media (-webkit-min-device-pixel-ratio: 1.25),
(min-resolution: 120dpi){ 
    /* Retina-specific stuff here */
}

While still perfectly usable, the initial –webkit-min-device-pixel-ratio setting has been deprecated in favor of min-resolution; there is no need to use it unless you have to cater to really old browsers!

Now, we could easily use CSS queries in all of our projects, but there may still be occasions where standard queries might not work. A good example is for a navigation that behaves differently at different sizes. Fortunately, there is a solution for this—we can achieve a similar effect using the breakpoints.js library. Let's delve in now and take a look.

So far, we've worked mainly with modern browsers. These handle media queries effectively, allowing us to display the right image at the right time. What if we had to support old IE browsers, for example, that can't handle media queries without some form of help? No problem—enter breakpoints.js, one of the many JavaScript/jQuery libraries available to help us mimic media queries. I feel an exercise coming on, so let's make a start building an example to see how it works:

At this point, try resizing the browser window. Notice how each of the text boxes resize. We're using image placeholders from the Placehold.it service at http://placehold.it/; these automatically resize in the same manner.

But hold on! A closer look at the CSS shows no media queries. This is the beauty of breakpoints.js; it allows us to replicate media queries for those browsers that don't support them natively. Sure, it's a little extra overhead; we can get around this using conditional comments (or Modernizr), so the overhead only appears when needed.

Let's move forward and take a look at a different method of switching images; so far we've used media queries to handle which image should be displayed. However, we're not limited to using them. We can use an alternative method in the form of source shuffling.

Source shuffling uses both jQuery and CSS—if JavaScript is disabled, then CSS media queries will kick in and perform a similar function instead. Let's dig into an example to see how it works and why this could potentially provide the best of both solutions to us.

The title of this exercise is a real mouthful, but serves to highlight an interesting experiment: "What if we could use data tags to switch images?"

The immediate benefit of source shuffling is that it keeps CSS media queries out of the HTML markup (to see what I mean, take a look at the HTML code used in Working with the <picture> tags in the next section.)

It's an interesting concept and one you may want to consider using; to see how it works, we'll use an adapted version of an example created by the UX designer Jordan Moore. This uses JavaScript-based Conditional CSS library by Jeremy Keith to great effect. To see what I mean, let's get going on a demo to see how it works:

The key to note in this demo is that we will only see the small.jpg image on mobile devices where the viewport is already smaller. On larger devices and desktops, either the medium.jpg or large.jpg images will be shown instead as dictated by the media query in effect.

When working in responsive design, we frequently have to provide different images and use a series of media queries to display the right ones at the appropriate time. This works fine, but is a little labor intensive. Instead, we can use the upcoming <picture> tag to produce a neater effect.

Let's dive in and take a look at how we can use the tag using these steps:

Now, we have our demo set up. Next, try resizing the browser window smaller or larger. Notice how the two images change, albeit at different response points. The key to this is the use of the picturefill.js polyfill created by Scott Jehl. This aims to replicate the functionality of <picture> until such time as the browser supports it natively and we can remove the fall back.

The library is called using this script block—document.createElement is used to create a dummy picture fallback element, as it doesn't exist yet at this point:

  <script>
    document.createElement( "picture" );
  </script>
  <script async="true" src="js/picturefill.js"></script>

We then provide the fallback code as follows:

  <p>Here's how that renders in the browser. Feel free to resize to see it change.</p>
  <img sizes="(min-width: 20em) 80vw, 100vw" srcset="img/small.jpg 375w, img/medium.jpg 480w, img/large.jpg 768w" alt="A random image">

This is followed by the native <picture> element, which will be supported by Firefox, Opera, and Chrome within the next few versions of each browser:

  <picture>
    <source srcset="img/large.jpg" media="(min-width: 768px)">
    <source srcset="img/medium.jpg" media="(min-width: 480px)">
    <img srcset="img/small.jpg" media="(min-width: 375px)">
  </picture>

It's worth getting to know the <picture> element. While it means that we have to have our CSS media queries in-line, it produces a cleaner result as we don't need to use individual media queries in a separate style sheet.

If you have spent any time working with media in a responsive capacity, no doubt you will find that some image formats don't resize well. To get around it, it may be necessary to provide several different versions of our image and set the code to pick the right one at the appropriate point.

Do we want to be doing that all the time? Somehow I don't think so. It's a real pain to produce all those different versions! There's a better way to achieve the same result if we switch to using the vector-based SVG format, which will resize smoothly without loss of quality. Let's delve into an example to see how it works:

The beauty of using SVG is that we can actually edit the content of the image using a text editor; SVG images are after all just plain XML files! SVG images are great for several reasons:

Using standard images such as PNGs or JPGs will work, but they won't resize properly beyond their native resolution; instead, we are likely to need several versions of the same image in order to view them properly. It's worth spending time getting to know the SVG format. There is a useful article by Nick Salloum at http://callmenick.com/2014/04/02/svg-fallback-with-png/, which extols different mechanisms we can use to provide fallback for SVG images.

If you really want to get into editing SVG images, take a look at http://css-tricks.com/using-svg/. It's a great article by Chris Coyier that shows us how we can edit the content to really alter its appearance.

One of the major problems we have when creating responsive content is the use of icons: their bitmap format doesn't scale well when resizing them. This is often the same for icon sprites; for example, if you resize the battery icons demo from earlier in the chapter, then you will soon notice how pixelated it becomes when anti-aliasing kicks in!

To get around this, designers may simply drop the use of icons; the alternative is to replace them with vector-based web fonts, such as the Font Awesome icons, available at http://fortawesome.github.io/Font-Awesome/. There is an excellent article online by Jason Cranford Teague at http://webstandardssherpa.com/reviews/responsive-webfont-icons, extolling the benefits of using them in the main due to their scalability with no loss of fidelity.

To see how they work in action, we're going to use some social media icons from Entypo, created by Daniel Bruce and available at http://www.entypo.com. For this tutorial, we're going to use a simplified version of an example created by Teague, which uses a number of icons. You can see the original article at http://webstandardssherpa.com/reviews/responsive-webfont-icons.

Perform these steps for this tutorial:

Let's move on and take a look at a couple of examples of real-world applications of responsive design, beginning with Building a responsive carousel.

So far we've covered a lot of different techniques to help us produce responsive content. Most of it has been simple examples in a development context. It's time to take a look at a couple of examples of real-world applications where responsive functionality has been put to good use. Our first example is in the form of a responsive carousel. There are dozens of example libraries online that can be used to create one, so there is no need to build from scratch!

Let's take a look at one of my favorites—ResponsiveSlides.js; it's a simple library that provides a useful solution, but doesn't try to achieve everything. We'll borrow one of their examples to see how it works.

There are plenty of examples of responsive carousels available online—two such examples are WOW Slider at http://wowslider.com/, with an example of what is possible at http://www.wowslider.com/responsive-image-gallery-glass-collage.html, Owl Carousel (http://www.owlgraphic.com/owlcarousel) and BXSlider, available at http://bxslider.com/. It is a matter of trying a selection and choosing the one that suits your requirements.

In the second of our two real-world examples, we're going to look at making a responsive map using Google Maps. Responsive maps, I hear you ask? Surely this should come automatically, right? Well no, it doesn't, which makes its use a little awkward on mobile devices. Fortunately, we can easily fix this; the great thing about it is that it only requires a little additional CSS:

If all is well, we will see a Google Maps image of Birmingham with our office marked accordingly:

At this point, try resizing the browser window. You will see that the map resizes automatically; the CSS styling that we've added has overridden the standard styles used within Google Maps to make our map responsive and accessible from any device we care to use.

Wow! We've certainly covered a lot over the last few pages! Let's take a moment to recap and let what we've learned sink in.

We began with a look at creating basic fluid images, which are a key to responsive design and should form the mainstay for any responsively designed site. We then covered some key points in the form of what image formats to use, as well as whether we need to use any vendor prefixes in our code. Next up came a discussion on some useful tips to cater to mobile devices. We saw how many are common sense, but particularly apply when designing for mobile devices.

Our first coding example came in the form of a look at catering to high-definition or retina images; we then moved on to examining how we can also use sprites to add responsive media to our projects. We then moved on to looking at sizing our available viewport space using both jQuery and CSS; these we can then use to determine what our media queries should look like. We also covered off how you can use JavaScript to define media queries as well, in the event we need to provide fallback support in our sites.

Moving on, next up we covered a couple of examples of how to switch images responsively—the first using data tags and the second using the upcoming <picture> tags. We also looked at a trick whereby we can provide two images at the same time but rely on the browser to pick which one it can support. We finished our look at using images in the form of a peek at how we can use web icons to serve content responsively and that these scale beautifully without any loss of quality. We then finished of the chapter with a look at two real-world examples in the form of building a responsive carousel and creating responsive maps.

In the next chapter, we'll take a look at the other major element of media content and how to add videos responsively to our sites.