You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

You can download the code files by following these steps:

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Responsive-Web-Design-with-HTML5-and-CSS3-Essentials. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/ResponsiveWebDesignwithHTML5andCSS3Essentials_ColorImages.pdf.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at copyright@packtpub.com with a link to the suspected pirated material.

We appreciate your help in protecting our authors and our ability to bring you valuable content.

If you have a problem with any aspect of this book, you can contact us at questions@packtpub.com, and we will do our best to address the problem.

A key part of RWD is working with the viewport or visible content area on a device. If we're working with desktops, then it is usually the resolution; this is not the case for mobile devices.

There is a temptation to reach for JavaScript (or a library such as jQuery) to set values such as viewport width or height, but there is no need, as we can do this using CSS:

<meta name="viewport" content="width=device-width"> 

or using this directive:

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

This means that the browser should render the width of the page to the same width as the browser window—if for example the latter is 480px, then the width of the page will be 480px. To see what a difference that not setting a viewport can have, take a look at this example screenshot:

This example was created from displaying some text in Chrome, in iPhone 6 Plus emulation mode, but without a viewport. Now, let's view the same text, but this time with a viewport directive set:

Even though this is a simple example, do you notice any difference? Yes, the title color has changed, but more importantly the width of our display has increased. This is all part of setting a viewport—browsers frequently assume we want to view content as if we're on a desktop PC. If we don't tell it that the viewport area has been shrunk in size (and that we have not set the scaling correctly), it will try to shoehorn all of the content into a smaller size. This will result in a page that will appear to be zoomed out, which doesn't work very well!

It's critical, therefore, that we set the right viewport for our design, and that we allow it to scale up or down in size, irrespective of the device. We will explore this in more detail, in Chapter 2, Creating Fluid Layouts.

When designing responsive sites, we can either create our own layout or use a grid system already created for use, such as Bootstrap. The key here though is ensuring that the mechanics of our layout sizes and spacing are set according to the content we want to display for our users, and that when the browser is resized in width, it realigns itself correctly.

For many developers, the standard unit of measure has been pixel values; a key part of responsive design is to make the switch to using percentage and em (or preferably rem) units. The latter scales better than standard pixels, although there is a certain leap of faith needed to get accustomed to working with the replacements!

Two key parts of our layout are of course images and text—the former though can give designers a bit of a headache, as it is not enough to simply use large images and set overflow—hidden to hide the parts that are not visible!

Images in a responsive site must be as flexible as the grid used to host them—for some, this may be a big issue if the site is very content heavy; now is a good time to consider if some of that content is no longer needed, and can be removed from the site. We can of course simply apply display: none to any image which shouldn't be displayed, according to the viewport set. However, this isn't a good idea though, as content still has to be downloaded before styles can be applied; it means we're downloading more than is necessary! Instead, we should assess the level of content, make sure it is fully optimized and then apply percentage values so it can be resized automatically to a suitable size when the browser viewport changes.

With content and media in place, we must turn our attention to media queries—there is a temptation to create queries that suit specific devices, but this can become a maintenance headache.

We can avoid the headache by designing queries based on where the content breaks rather than for specific devices—the trick to this is to start small and gradually enhance the experience, with the use of media queries:

<link rel="stylesheet" media="(max-device-width: 320px)" href="mobile.css" /> 
<link rel="stylesheet" media="(min-width: 1600px)" href="widescreen.css" /> 

We should aim for around 75 characters per line, to maintain an optimal length for our content.

Accessibility plays a key role in responsive design. Our content should be as intuitive as possible, with every single piece of information easy to access. Responsive design places great emphasis on making our design self-explanatory; there shouldn't be any doubt as to how to access information on the site.

Even though our mobile version may not contain the same information (which is perfectly accessible), it nonetheless must be engaging, with appealing colors, legible text (at all sizes), and a design that retains visual harmony and balance with our chosen color scheme.

The success of our site is determined by a host of factors, of which one of these will be how our content is organized in the layout. The content should be organized in such a way that its layout makes it easy to process, is simple and free of clutter, and that we're making full use of the available viewport space for the device we're targeting.

We must also ensure our content is concise—we should aim to get our point across in as few words as possible so that mobile users are not wasting time with downloading redundant content. Keeping our options simple is essential - if we make it too complicated, with lots of links or categories, then this will increase the time it takes for visitors to make decisions, and ultimately only serve to confuse them!

At this point, it is worth pointing out something - over time, you may come across the phrase adaptive design, when talking about responsive design. There is a subtle but key difference between the two, and either can be used as a principle when constructing our site. Let's take a moment to explore what each means, and the differences that might affect how we go about constructing our sites.

Although there are lots of tips and pointers we can use to help improve our responsive development, there is one subject that is worth exploring in more detail—touch.

Why? The answer is simple—working responsively is not just about writing code; anyone can write code. The difference though, and that which separates great developers from the crowd, is the thought given to how that site looks and works. Care paid at this point will separate exceptional sites from the also-rans; to get a feel for the kind of decisions and thoughts one might go through, let's take a look at what we might have to consider when designing for touch:

Source: The Next Web (http://www.thenextweb.com)

Hover stages are a no-no in responsive design—these do not exist. Any calls to action should be based around tapping, so make sure your design takes this factor into consideration.

Phew, there are a few things to think of there! The key thing though is that while writing code is easy, creating an effective responsive design takes time and resources, and should always be a continuous affair, so our designs can stay fresh and up to date.

It's time for us to move on to a different subject, now that we've explored some of the guidelines and tips we can use to help with responsive development, it's time for us to consider our workflow. We may already have an established one for producing standard sites, making a shift to incorporate responsive design may require us making some changes to our processes, so let's go and explore what a typical workflow could look like when working with responsive design.

This initial stage is the same for any sites, but is particularly important for responsive design, given the different viewport sizes we have to support in our site. It's all about getting to know the client and their requirements. We must get an understanding of our client's business, their competitors, and what they are trying to achieve.

It's at this point we should be asking questions such as, "Why would people come to your site?", "What is the main goal you are trying to achieve?", and "Who are your main competitors?" The more we ask, the more we can understand and therefore better advise our clients on the best solution to fit their requirements.

When we've gathered all of the knowledge needed to construct our site, we now need to plan how it will look. We can start with the initial concept, but rather than work on the layout as we might have done before, we should concentrate on the content elements, and creating user stories and the information architecture. We can then put this together in a rudimentary HTML wireframe. At this stage, layout is less critical; it's key that we get the right view of information, before focusing on where it sits on the page.

At this point, we now need to focus on writing our content in textual form. This often under-rated step is probably the most important of the whole process; without it, people won't come to see the site, and there is no point in designing a layout if we don't know what will fill it! A useful tip is to keep styling to a minimum and to concentrate on the content; at least initially, we can see how it will display in a long, continuous format, and if it works for those who use screen readers. Don't worry though, we can always refine the text during the prototyping stage; at this point, we need something to start with, but it will be unlikely we get it right first time.

For our next step, forget using PhotoShop; it takes forever and is a real pain to make corrections quickly! The agile process is about making quick and easy changes and there is no better medium than traditional pen and paper. We can even print off the plain text content and sketch around, it if that helps, it will save us hours of development time, and can even help reduce those occasions when you hit the developer's block of...what now?

With the design sketched, it's time to create a prototype. This is when we can see how the layout will respond to different viewport sizes and allow us to highlight any potential challenges, or react to any issues that are reported by our client. It's good to be aware of the various breakpoints, but ultimately we should let our content determine where these breakpoints should be set in our design.

We might be used to prototyping our design using PhotoShop, but a better alternative is to switch to using a browser. We can use a service such as Proto.io (https://proto.io/) or Froont (http://froont.com/). This gives us extra time to get the harder elements right, such as typography; it also helps to remove any constraints that we might have with tools such as PhotoShop.

Although we may still be at a prototype stage, it's important to introduce testing early on. The number of breakpoints we may end up having in our design means that testing on multiple devices will take time! As an alternative to running a big test and reveal, we can instead perform multiple tests and reveals. This has the benefit of reducing the impact of any rollbacks (if something doesn't fit requirements), but also helps to keep the client involved with the project, as they can see progress take place during development.

The one thing we absolutely must do is to test over multiple devices. It's an expensive proposition to maintain a test suite with these devices, so it's worth asking colleagues, friends, and family to see if they can help test for you. They can at least browse the site and help pinpoint where things don't look right (to use customer parlance). It's up to us to work out where the root cause is, and implement a fix to help improve the user experience.

You will notice that I italicized the word experience at the start of this section—the key point here is that in responsive design, the experience does not have to be identical across all devices; it must be useful though, and allow our visitors to interact with us as an organization. In other words, if we worked for a theater, we might limit our mobile offer to simply booking tickets, and let the main desktop site manage everything else.

This is perfectly valid; while limiting a site, mobile ticketing might be considered by some as very restrictive. The concept is still technically sound, as long as the user experience is acceptable.

It's worth noting that we could have set a specific width using width=<value>. This is great if we need a certain width to display our content; if the orientation changes from portrait (320px) to landscape (360px) for example, then the viewport's content will be automatically scaled up and down to reflect these changes. If, however, we had set a device-width as a maximum, this implies that no scaling is need and that the browser should adjust the content within it to fit.

A key part of responsive design is to make the move away from using pixel values to working with em or rem units. In our examples (and the viewport demo from earlier in this chapter), we used both pixel and rem units. Although this works well, we still have a dependency on parent elements. Instead, we should consider using an alternative for working with viewports. They are:

As a unit of measure, these equate to 1% of the viewport area that has been set; the beauty though is that they remove any dependency elements, and are calculated based on the current viewport size. Browser support for them is currently very good:

Source: http://caniuse.com/#search=vh

Leaving aside the slight quirks with more recent versions of Internet Explorer, this is a useful option that combines the ease of units, with the flexibility of using percentages, in our designs.

Let’s move on—we’ve introduced flexible grids and explored how setting a viewport is critical to displaying content correctly. It’s time we moved on and explore some of the benefits of incorporating a grid system into our layout, and dive into the internals of how they work as a principle in responsive design.

Taking a closer look at our code, we will find that a large part of it uses standard attributes, which we might find on any site. The code that is of interest to us starts on line 50; to understand its role, we first need to get our heads around the basic concept of flex layouts:

Source: W3C

In a nutshell, items are laid out following either the main axis (from main-start to main-end) or the cross axis (from cross-start to cross-end):

With this in mind, let's explore some of the flexbox terms that have been used in our code; the initial few styles are standard rules that could apply to any site. The code of interest to us starts on line 29.

If we scroll down to that line, we are met with this:

Our first attribute, display: flex, defines the container which contains the flex items; here, we're setting it to show items in rows, and to wrap from left to right. If we had a number of columns in our layout, and by this I mean more than just two or three, then we might use align-items and justify-content to ensure that each column was evenly spread throughout the row, irrespective of the width of each column.

With the .grid defined, we need to style our grid-cells, or the containers where we host our content. There are several properties we can apply; the one we've used is flex, which is shorthand for flex-grow, flex-shrink, and flex-basis. In our case, it is recommended that the shorthand version be used, as this will set the other values automatically; we've set flex-grow to 1, which indicates how much it should grow, in relation to other flexible items in the same container.

The next property of interest is in the .nav rule. Here, we've used flex-flow again, but this time we also justify-content; the latter controls how items are packed on each row (in this case, toward the end of the line):

Our last block of code of particular interest is this section, within the large screen media query:

The order property simply specifies the order of each item in our flex container; in this case, we have .aside-1 and .aside-2 in position 1 and 2 respectively (not in shot), with the .main in the middle at position 2.

Let's move on. We've explored some examples of what is possible now, but there is at least one downside with using flexbox. The technology works very well, but can add a fair amount of code and complexity when implementing in a site.

It's time to look for something simpler to use, which doesn't require quite the same effort to implement; enter CSS grid templates! This is still an early technology, with minimal browser support, but is already easier to implement. Let's dive in and take a look in more detail.

For our next demo, we're going to make use of an example created by the developer Rachel Andrew, at http://codepen.io/rachelandrew/full/LGpONE/; we'll be replacing the images with ones from Flickr, depicting pictures of my favorite European town, Bruges. No, it's not to do with the lace, before you ask: good food, fine wine, great atmosphere, stunning chocolates for sale...what more could you ask for, I wonder?

But I digress. Before we get into creating our code, there are a couple of points we must bear in mind:

Without further ado, let's make a start on our demo:

Okay, granted. It's probably not what you might expect in terms of styling, but this demo isn't about making it look pretty, but the basic grid effect. There are nonetheless some important concepts that are good to understand, so let's dive in and explore what took place in our demo in more detail.

Earlier in this chapter, we explored how flexbox can be used to create a grid layout; if we were to compare CSS styling, it is easy to see that on balance, we need to provide more styling when using flexbox than using CSS Grid Layout.

The only styling attribute that we've used in our core styles is box-sizing, which we set to border-box. Nothing else has been used at this point—all of our CSS Grid Layout styles have been set within two media queries.

Our first media query sets the .wrapper class as our grid container. Note that we've only need to set it once, as it will cascade through to larger viewports that are 500px or greater in size.

Once the grid container is assigned, we then specify the grid columns for our template - the 1fr value assigned represents the fraction of free white space in the grid around each cell's content (hence the fr unit). We then finish up by specifying grid-row or grid-column in both media queries - these values define a grid item's location within the grid; these two terms are shorthand for grid-row-start, grid-row-end, grid-column-start and grid-column-end respectively.

To embed those videos, we need to use iframes, which unfortunately do not maintain aspect ratio by default; we can work around this with a CSS solution by Thierry Koblentz.

Let's for argument's sake say that we have a YouTube video, such as this one, titled The Big Buck Bunny, by the Blender Foundation:

(c) Blender Foundation | www.bigbuckbunny.org

Looks okay, doesn't it? Granted, we can't immediately tell it is a video from YouTube, but this next screenshot clearly shows it is:

Hold on; that doesn't look right, does it? The screenshot was taken in Google, but set to emulate the screen estate of a Galaxy S5 mobile phone, but it clearly shows that the video is not responsive.

To see this in action, extract a copy of youtube.html from the code download that accompanies this book to our project area, then run it in a browser. Activate your browser's responsive mode (or device mode, depending on browser) and resize the screen to 360px by 640px. You will soon see how it doesn't resize well!

How do we fix this?

The trick is to create a box with a proper aspect ratio, say 4:3 or 16:9 (through zero height and bottom padding in %), and then fit the video and stretch it inside the box up to the box dimensions by positioning it absolutely with respect to the box. The bottom padding acts as the width that helps to maintain the aspect ratio. Let's alter our code to fix this issue:

This looks much better! With some simple styling, we have the best of both worlds; we can let YouTube do all the heavy lifting while we concentrate on making our video available from our site on multiple devices. The CSS we used forces all of the video content to the full width of the .video-box-wrapper container, which in turn is positioned relative to its normal position. We then add 56.25% to the bottom to maintain the classic 16:9 aspect ratio and provide a little extra padding at the top so it doesn't appear to go off screen!

There will be occasions, though, when we have to host our own videos; this might be for controlling visibility or preventing adverts from being played, if we were to host it externally. To achieve this, we can use the now current HTML5 <video> element to render content on a page; let's take a look and see how this works in action.

If hosting videos on an external source is not possible, then we must host locally; for this, we can use the native HTML5 video tag, which looks something like this:

<video controls> 
  <source src="video/bigbuckbunny.webm" type="video/webm"> 
  <source src="video/bigbuckbunny.mp4" type="video/mp4">  
</video> 

In the past, codec support for the HTML5 element has been split across each platform; in 2015, Firefox added support for H.264 to its browsers across all platforms, which goes a long way to rationalize support for HTML5 video. At present, support for the two formats (MP4 and WebM) is good, but not 100% across all browsers – this screenshot indicates the current state of play for desktop and mobile browsers for the MP4 format:

Source: CanIuse.com

In contrast, support for the WebM format is not quite so complete:

Source: CanIuse.com

In reality, the only format we need to worry about using is MP4; we can use WebM format if desired. If we do so, then it must come first in the <source> list; otherwise, the browser will pick the first available supported format (in this case, MP4) and not use WebM!

Now that we've been introduced, let's move on and put it into practice, with a simple demo to illustrate how the <video> element works in action.

If our requirements are such that we have to host a video ourselves, then implementing it using the HTML5 standard tags is very easy; it consists of setting any number of different sources within the <video> tags so that we can play the same video using the supported format for that browser. Let's dive in and take a look at how we do it:

The result looks perfect—the question is, which version of our video is being used? One way to find out is to right-click on the video, while it is still playing, then click on Save video as.... If all is well, we should see a Save As dialog box open, ready to save the WebM format if we're using FireFox, Chrome, or Opera; otherwise it will be MP4 (if using IE).

<video controls> 
    <source src="video/bigbuckbunny.webm" type="video/webm"> 
    <source src="video/bigbuckbunny.mp4" type="video/mp4"> 
</video> 

video { 
   max-width: 100%; 
   /* just in case, to force correct aspect ratio */ 
   height: auto !important; 
} 

If you spend any time on the Internet, it's possible you've come across sites where the developer hasn't used images as a background, but video.

This isn't entirely new as a concept; it's been around for a couple of years now. If done with care, it can work very well. It's a perfect candidate for making full-size video as a responsive background. The great thing about it is that we can make it responsive using pure CSS. That's right, no need for any JavaScript.

For our next demo, we'll take a break from creating content. This time around, we'll run the demo from the code download that accompanies this book, and take a look at the code in more detail later in the demo. We'll be using videos from the Big Buck Bunny project, created by the Blender Foundation as our background; over this, we'll overlay a simple block of sample text, generated using the Lorem Ipsum generator.

To see this in action, go ahead and run the fullscreen .html demo from a copy of the code download that accompanies this book. If all is well, you will see the video play behind a simple <div> with text:

If we take a look at our code in more detail, we can see the video element in use; it's been set to autoplay, with sound muted and a poster (or placeholder) image set. The real magic, though, lies in the CSS styling, so let's explore this in more detail.

Exploring what happened

The trick that makes our video work is in this code. We need to set two media queries with 16:9 aspect ratio (one as a min-aspect-ratio, another as the max) so that our video displays correctly on the screen:

When resizing it though, it will show white space. We fix that by setting negative margins, which makes the viewport much wider, and allows us to center the content on screen:

A key point to note is the values used for height, top, left, and width; although these seem extreme, they are required to help center the video on screen when viewing the content with a 16/9 aspect ratio set.

Perfect! Our video plays well. We can see the content without too much difficulty. Everything should be good, surely? Well, yes and no; concepts such as background video are not without their risks; it's important to understand where things might fall over if we're not careful. Let's pause for a moment and consider some of the potential traps that might upset the proverbial apple cart, if we're not careful with our video.

In our previous example, we explored the concept of adding video as background content. It's a fashion that has taken off within the last couple of years, and provides an interesting effect, that is different to seeing the standard images we might otherwise see!

It's not without a certain element of risk though; there are a few pointers we must consider, when adding video as the background content:

Even though we have some clear pointers that should be considered, it should not stop us from using this effect; I'm one for pushing out the boundaries of what is possible, provided we do it well!

Question—we've worked on making videos responsive, but what about audio content?

Well, we can apply similar principles to the HTML5 <audio> element; instead of setting a specific width, we can use max-width and set a percentage figure to control how wide it displays on the screen.

The code to achieve this is very simple, and should by now be familiar—let's take a look at what is involved:

At first glance, it may not look special, but then the <audio> element isn't meant to look anything out of the ordinary! The key here though is when we resize the browser window; we've set a max width value of 100%, but have constrained this by setting an upper limit of 50rem in the width attribute. No matter how many times we resize our window, the audio player will fill the full width, but not go any wider than 50rem.

Let's move on and put our new-found knowledge to the test to create a practical example—how about making a video fullscreen, and responding to changes in the browser viewport automatically? Setting up video using this technique is always fraught with controversy, but I'm not one to shy away from a challenge, so without further ado, let's dive in and see why we must step carefully when using video at fullscreen.

Throughout the course of this book, we've concentrated on using the core technologies of HTML5 and CSS3; in many cases, this is all we need, but there will come a time when we have to use other technologies to help fulfill a task, as we've outgrown the art of possible with plain CSS and HTML code.

Thankfully, there are lots of options available online to help with making videos responsive, and to take our skills. It goes without saying though that we should always ask ourselves if our need for another library is because the realities of life mean that we can't achieve our task without using it or if we've simply become too lazy!

If indeed we do need to download and use an additional library, there are a few good options to try out, which include:

A small word of caution—a number of the video plugin libraries for jQuery haven't been updated for some time; you may well find that they no longer work properly with more recent versions of jQuery. This isn't necessarily a bad thing, as support for the HTML5 <video> and <audio> elements is now excellent; this renders many of these libraries surplus to requirements!

Phew! We're almost through this part of the journey, but before we move onto taking a look at using media queries in the next chapter, there is one more part of making responsive content; how about the text we have on our sites? It might not immediately strike you as being one we would associate with videos and text (at least in the context of making content responsive), but all will shortly become clear.

When working on non-responsive sites, it's likely that sizes will be quoted in pixel values; it's a perfectly acceptable way of working. However, if we begin to make our sites responsive, then content won't resize well using pixel values; we have to use something else.

There are two alternatives: em or rem units. The former is based on setting a base font size that in most browsers defaults to 16px; in this example, the equivalent pixel sizes are given in the comments that follow each rule:

h1 { font-size: 2.4em; }      /* 38px */ 
p  { line-height: 1.4em; }    /* 22px */

Unfortunately, there is an inherent problem with using em units; if we nest elements, then font sizes will be compounded, as em units are calculated relative to its parent. For example, if the font size of a list element is set at 1.4em (22px), then the font size of a list item within a list becomes 30.8em (1.4 x 22px).

To work around these issues, we can use rem values as a replacement, these are calculated from the root element, in place of the parent element. If you look carefully throughout many of the demos created for this book, you will see rem units being used to define the sizes of elements in the demos.

The rem (or root em) unit is set to be relative to the root, instead of the parent; it means that we eliminate any issues with compounding at a stroke, as our reference point remains constant, and is not affected by other elements on the page.

The downside of this is support—rem units are not supported in IE7 or 8, so if we still have to support these browsers, then we must fall back to using pixel or em values instead. This of course raises the question: should we still support these browsers, or is their usage of our site so small as to not be worth the effort required to update our code?

If the answer is that we must support IE8 or below, then we can take a hybrid approach; we can set both pixel/em and rem values at the same time in our code:

.article-body { 
  font-size: 1.125rem;  /* 18 / 16 */ 
  font-size: 18px; 
} 
 
.caps, figure, footer { 
  font-size: 0.875rem;  /* 14 / 16 */ 
  font-size: 14px; 
} 

Notice how we set rem values first? Browsers that support rem units will use these first; the ones that don't can automatically fall back to using pixel or em values instead. The values in each comment are the pixel equivalents; if, for example, we divide 18px by 16px (as the base value for all sizes), we would arrive at 1.125, as indicated in the text.

If we want to take it further, then there is another alternative we can explore; how about using viewport units?

These effectively combine the best of both worlds; a viewport unit (or 1vw) is 1% of the viewport axis. So, if we had a viewport of 50 cm wide, a single vw unit would be 0.5 cm. We can specify sizes in the same way as we would do for pixel, em, or rem units. Take a look at this little extract, which gives a flavor of what it would look like:

h1 { font-size: 5.9vw; } 
h2 { font-size: 3.0vh; } 
p { font-size: 2vmin; } 

The beauty though is no matter what size the viewport, the font size will always appear correctly, as it will automatically resize if the view port is changed.

Okay, at this point, we've added responsive capabilities to our text; our sites are looking pretty good....I can see a but coming....

At present, support for responsive text (and in particular vw or rem units) is excellent; browsers that will choke on these two units are few and far between. However, there may come a time when we need additional help; unlike images or video content, there are not many options available to choose from! The two best examples are FlowType.js, available from http://simplefocus.com/flowtype/, and FitText.js, from http://fittextjs.com/.

The catch though is that these libraries haven't been updated for 2-3 years, so are not likely to work with recent versions of jQuery. It's a good indicator of how well responsive text has come along over the years, and that we really should be using it natively, rather than relying on JavaScript!

If we take a look at the example query in the previous section, we see that part of it is made up of the type of media in use. This is just part of the query. All media queries come in two parts, with the first part controlling how our CSS will be displayed, with the second part taking care of when it is displayed.

Take a look at this example:

<!-- CSS media query on a link element --> 
<link rel="stylesheet" media="(max-width: 800px)" href="example.css" /> 
 
<!-- CSS media query within a stylesheet --> 
<style> 
@media (max-width: 757px) { 
  .sidebar { 
    display: none; 
  } 
} 
</style> 

This illustrates two ways of referencing media queries: the first example doesn't specify the media type, so we can infer it will be all by default; the second part of it states that it will only apply when the width of our window is at least 800px.

The second media query one doesn't specify the media type either, so again all will be inferred as the default; this time, the .sidebar element will not be displayed if the window width is less than 600px wide.

Let's see what all media types can be used:

In addition, to this, we have a number of features that we can use to control the trigger for displaying the content; it's worth getting to know them, as they all play an important role, but work in different ways. Let's take a look at the list in more detail and learn what each of them does in turn.

Adding a query that specifies the media target is only half the picture; we also need to give it something that controls when to display it! To achieve this, we can provide one or more conditions that must be satisfied in order for content to be styled or displayed.

Let's have a look at some of the options available:

The key here is selecting the right attribute against which we should run our test; a great example is checking orientation so that we can determine if a tablet is in portrait or landscape mode. We will make good use of some of these query tests later in this chapter.

Okay, time to move on. The theme so far has been what we can achieve by just using a browser and a text editor. This may seem limiting at first, but I maintain that too many people resort to using additional help (such as using jQuery) to create queries when it isn't always necessary to do so. In the main this will work, but there are some points that we should consider:

Okay, let's move on: it's time to get physical, and stuck into something more practical! We've covered some of the different facets that make up queries and explored some of the considerations we need to allow for, when working with just a browser and text editor. Before we get too practical though, we need to cover one more topic. There are occasions when we need to test for multiple conditions. We can do this using logical operators. Let's take a quick look at some of these in more detail.

When composing media queries that require multiple tests, we can make use of logical operators to confirm if one or more CSS rules should be applied to our content. If we use logical operators, we need to encapsulate each attribute that is tested in parentheses; otherwise, it will generate an error in our code.

Let's take a look at some of the more common examples of operators:

So far, we've talked about the basics of what a media query looks like: let's explore how we can use them to manage content by identifying where our designs break at different screen sizes. These breaks, or breakpoints,are what make media queries work – whilst it is clearly key that we get them right, it is also important to know when we should and should not use them...

The media queries we've already outlined should cover a wide range of scenarios; there will be occasions when these won't suffice, and our site isn't working as expected.

What do we do? Well, we are not limited to using the standard queries we've already covered; we can absolutely create our own!

Creating a custom breakpoint is very easy, as long as we do it the right way; done incorrectly, and we can create unnecessary breaks that have a limited use or an unintended knock-on effect to other devices. To see what we mean, let's work through a (theoretical) example.

Imagine your site has been resized to around 335px, and we see it is a little out of kilter—there are a number of elements that don't quite fit properly. To better manage content at this breakpoint, the temptation would be to write a query such as this:

@media only screen and (max-device-width: 345px){ 
  /* Styles */ 
} 

We would add our changes in the area headed by /*Styles*/.

Sounds reasonable, right? It would be, if it weren't for one thing: we've now just created a whole new set of problems for viewing devices that have a width lower than 345px!

The key to solving this issue is to not simply use a bigger pixel value, as this may break the layout for other devices—this includes mobile devices, in portrait or landscape modes. The right way to fix this is to identify the exact circumstances where our query fails, and to either adjust the query to better match the circumstances or (ideally) work out if the design itself can be tweaked to avoid the need for a query.

So, for example, if our site broke between 325px and 345px, and that the failure was in portrait mode only, we would create a media query such as this one:

@media only screen and (min-device-width : 325px) and (max-device-width : 345px) and (orientation : portrait) { 
  /* Styles */ 
} 

How does this help us? Well, refining our query to be more explicit avoids any possible conflict with more generic queries that we might have already created. We're also making the threshold limits clearer too; we won't trigger the query unless we can match all three conditions at the same time.

Some developers may ask why we simply don't just fix the available viewport; this changes size when we change orientation, so surely the content will adjust to fit, right?

Well, yes and no. It's all about understanding where content is positioned, and the types of devices we want to support, in addition to desktops. We should not forget that it is perfectly valid to have a layout that is different in portrait mode to those in landscape; try looking at Packt's site in landscape and portrait modes on an iPad!

At the time of writing, an extra element is displayed in portrait mode, but it is not present in landscape orientation. If one of the elements in the portrait mode was broken and not displaying correctly, then simply specifying numerical breakpoints will not work. To fix the issue, we must also specify the affected orientation, otherwise fixing one mode may break another.

Okay, so we've created a bunch of media queries, ready for implementing into a site. We're good to move on and start building some examples, or are we? If I said to hold fire for a moment, you would very likely think I've lost my marbles; but as always, there is a good reason. Let me explain.

A drawback when using media queries is that no two sites will be the same; this means that we can't always reuse standard queries in multiple sites. There will be times when we have to create custom breakpoints to satisfy a requirement for a site; the trick is to know when and where our site may need extra attention, over and above the normal breakpoints we might have used in our site.

Creating custom, ad hoc queries is easy, but we do run the risk of creating too many, which undermines the whole concept of responsive design. Can we get around this? Well, yes we can; it involves a shift in our approach to designing, which is not to focus on viewport sizes, but our content instead.

Up until now, we've covered how we can use breakpoints to control what is displayed, and when, according to which device is being used. Let's assume you're working on a project for a client and have created a series of queries that use values such as 320px, 480px, 768px, and 1024px to cover support for a good range of devices.

No matter what our design looks like, we will always be faced with two issues if we focus on using specific screen viewports as the basis for controlling our designs:

So, hold on. We've created breakpoints, yet this can end up causing us more problems? If we're finding ourselves creating lots of media queries that address specific problems (in addition to standard ones), then we will start to lose the benefits of a responsive site; instead we should re-examine our site to understand why the design isn't working and see if we can't tweak it so as to remove the need for the custom query.

Ultimately, our site and target devices will dictate what is required—a good rule of thumb is if we are creating more custom queries than a standard bunch of four to six breakpoints, then perhaps it is time to recheck our design!

As an alternative to working with specific screen sizes, there is a different approach we can take, which is to follow the principle of adaptive design and not responsive design. Instead of simply specifying a number of fixed screen sizes (such as for the iPhone 6 Plus or a Samsung Galaxy unit), we build our designs around the point at which the design begins to fail.

Why? The answer is simple. The idea here is to come up with different bands, where designs will work between a lower and upper value, instead of simply specifying a query that checks for fixed screen sizes that are lower or above certain values. Don't worry for now if it doesn't entirely make sense just yet; for now, the key here is that we're creating designs that mean we can reduce the need to support so many devices.

Let's put this theory into practice, and start creating some demos to show off how we can use media queries in practice.

Making it real—what a title! There is a good reason for it. When exploring new concepts, one of my pet hates is exploring a demo that is so minimalistic as to not include anything that gives a true picture of the functionality that I want to begin using in my development.

Creating media queries should not be an exception. In our previous example, we created some test queries to see how three boxes would interact when the browser window is resized. To put this into context though, requires something a little more in-depth; one could do worse than explore how we might add similar queries to a portfolio page that might be part of a new or existing site. For our second demo, we're going to create a simple web page template, then begin to add and develop queries that allow it to be used on mobile devices.

Let's make a start:

A perfectly presentable page, I hope you will agree. It shows off two of my favorite things perfectly: my love of coffee and the Scrabble board game! I always say coffee must be the secret tool in many developers' armories, but I digress…

Try resizing the screen; for argument's sake, let's resize it to 414 x 736, or the equivalent required for an iPhone 6 Plus:

We can use Chrome's device mode to switch the orientation to landscape:

We can see that the site realigns itself:

It's a simple, clean design. The key here is that we can use this as a basis for adding more queries that support other devices. There are some important concepts that we should explore in more detail, so let's take five for a moment, and see how media queries play their part in our demo.

Exploring what happened

Many of the styles used in this example cater for styling our page; the key rules for us start on lines 33 and 50, where we style for an iPhone 6 Plus in portrait and landscape modes, respectively. Let's take a look at these two rules in more detail:

@media screen and (max-width: 414px) and (orientation: portrait) { 
... 
} 

This rule states that the screen width must have a max-width of 414px or less; if it is bigger and still showing in portrait mode, then the rule will not apply.

Within this rule, we've taken styles already used in the main block and applied changes that allow us to maintain the desired effect when viewing the site on an iPhone. A perfect example is the #banner block; in the main set of styles, we set a number of attributes to position it on screen:

#banner { float: left; margin-bottom: 0.9375rem; width: 100%; } 
#banner { height: 15rem; width: 44.5rem; background-image: url('../img/coffeebeans.png');  max-width: 100%; } 

However, that won't suit being displayed on an iPhone, leaving aside how big the image is at 717px by 214px. It also weighs in at a hefty 102KB! Clearly, we don't want to keep downloading such a large image on a mobile device (where Internet access is likely to be metered), so we need to do something else.

Instead, we have a smaller version in use, in the form of coffeebeans-small.png. This one is a more palatable 33KB, and sits in the top-right corner of our page when viewed on a mobile in portrait mode. We hide the original as it is not needed:

@media screen and (max-width: 414px) and (orientation: portrait) { 
... 
  #wrapper > header > img { float: right; display: block; } 
... 
  #banner { display: none; } 
} 

As soon as we flip to using it in landscape mode, this rule kicks in:

@media screen and (max-width: 736px) and (orientation: landscape) { 
... 
  #wrapper > header > img { float: right; display: block; } 
... 
  #banner { display: none; } 
} 

Notice though we don't need to change the rule. The image stays the same size and is already set to float to the right, so the rule can simply be reused. We have to specify it here too; otherwise, it won't display at all. To see the difference, try setting the demo using Google Chrome to emulate iPad mode:

We can see that even though the base code uses coffeebeans-small.png in the #banner <div>, our media queries have replaced it with coffeebeans.png.

Tip

You may notice that the media query widths are not set in rem units; this is purely so we can match them with the Device tool in Chrome. You can easily set them to rem units if you prefer to do so.

We've purposely kept the rules in our demo simple; they illustrate how, with little effort, we can get our page to display properly in both desktop, iPhone 6 portrait and iPhone 6 landscape modes perfectly. We can then reuse the same principles to extend support to cover other devices; the trick is to make sure that we use a breakpoint that covers enough devices so that we don't have to add more than is necessary to our site.

Let's change tack now, but stay with the Apple theme. No, I'm not thinking of food! How many of you are lucky enough to own an iPad? If the answer is yes, then this next demo will be of interest. For many standard devices, we are limited in terms of what resolution we can use when displaying images.

Enter a great trick. How about the ability to display higher-resolution images? We don't need to download anything to help with this. Most modern browsers can do this out of the box; all we need is the appropriate media query to tell browsers when to use them.

The advent (and some may say meteoric rise) of mobile devices has introduced an opportunity, supporting higher resolution images.

Most users can't distinguish individual pixels on standard PCs. When viewed at typical distances, some websites would appear too small to use! Instead, the PC will revert to a more realistic resolution, such as 1,440px.

To give a smoother view, some devices pack in extra pixels; this has the effect of making individual pixels harder to view, and images super crisp in appearance. This was started by Apple, who marketed them as Retina displays; others have begun to follow suit and create devices capable of supporting high-res images.

Thankfully, we don't need expensive iPhones or iPads to add support. We can do this with a media query and use Chrome's Device tool to simulate testing it. To see how, let's create a simple demo that switches between two images of a Phalaenopsis or Moth orchid plant. To tell which image is displayed, each will show the resolution in the top right corner of the image:

There are two points of note here—one is the setting on the left (Responsive), while the other is DPR or device pixel ratio. To trigger displaying the higher resolution image, try changing the setting on the left to iPhone 6 Plus:

Notice how the DPR setting has jumped to 3.0, and that our image has changed:

Hopefully, you will agree that this is a simple way to add support. Using Chrome, we can get a good representation of how a high-res image will appear; it is worth noting that it should still be tested on a proper device, as even Google can't entirely emulate specific devices from within their browser!

Exploring how it works

At this point, I am sure you will be asking how this all works. It's a simple trick. The key to it is the naming convention we used for the images at the beginning of the demo.

Remember how I said they should be saved as they are from the code download, and to not change the names? The reason for this is that we make use of this in our demo. Apple devices (since iOS4) expect to see the @2x in the filenames to denote a high-res image:

We then make use of that with our media query, which is only set to display the higher resolution image, if our min-resolution was detected to be 120dpi or greater.

Note

As an aside, you may see min/max-device-pixel-ratio being used. This is required to support recent versions of Safari. All other browsers can use min-resolution without issue, although not all support the dppi or dpcm unit formats that can also be used.

The power of media queries means we can tailor support for higher resolution images to those devices that can support them; if the device is not able to do so, then standard resolution images can be displayed instead.

Okay, let's change tack now. Although writing media queries is a straightforward task, there may be instances where even the best developer doesn't get it quite right! This could be anything from missing the viewport tag to inadvertently writing queries that clash with each other. Let's take a moment to explore some of the more common points where we might trip up, and take a look at a few pointers to help get us back on track.

Analysis shows that if a page takes longer than 4–5 seconds to load, then customers will frequently vote with their feet (that is, walk away). Any delay of more than a second can equally lead to a poor user experience.

A great source that can help us understand where some of our issues are is that behemoth, Google. We may knock it for being omnipotent, but it clearly knows some useful tricks!

Google states that our page doesn't have to entirely load within 4–5 seconds, but should be usable within this time; any content that is of a lower priority can be put below the fold or loaded in the background.

At a basic level, Google recommends that our server response time should be less than 200 ms—we should also explore aspects such as client-side rendering to help reduce the time taken to load our content:

Although much of this applies to any site, this is particularly important for responsive sites, given the extra code required to manage the experience for mobile devices.

Google also recommends that we should consider performing these tasks:

In addition, we can explore the use of other tricks to help with performance. These include the following:

If we want to explore things further, then there are some more advanced, invasive changes we can use to help optimize our site. These involve more work, so should be planned as longer term changes:

It takes time to optimize a site, but the effort spent in refining it will pay dividends in increased patronage and ultimately increased sales. The trouble is, we won't know how well our site performs unless we test it; let's explore some of the tools we can use to help gauge how well our site is operating, in more detail.

For our test, we'll start with a desktop browser—we'll use Google's Chrome as it has a good set of tools; other browsers can also be used, but you may not get quite the same results. Let's make a start, using Amazon as the basis for our test:

Here's what we need to do:

At this point, we will have a set of results we can browse through, similar to this extract:

At first, these results may not make sense, but the details we want are at the foot of the window.

This shows the number of server requests made, the amount of content transferred, and the times taken to initially parse the DOM (DOMContentLoaded); then, fully download the content (indicated by Finish and the Load event being fired).

Even though Amazon's site downloads a reasonable amount of content, they've made good use of some of the tricks we've covered, to help reduce bandwidth usage and increase page rendering speed. How can we tell? Try clicking on the bottom two links shown in the screenshot (or links 4 and 5 in the asset list shown within the browser).

The first link shows a minified CSS style sheet; if we look at it in more detail, it is possible to surmise that some of the links within were generated using an automated process. The PNG filename in one example is over 70+ characters long! The use of long names will increase the file size of the file concerned; images need to be accurately named, but with sensible filename lengths!

Considering the size of the page and the number of requests, it is possible to think that this website faces performance issues. However, if we look more carefully, we can see a lot of content is being loaded in the background. This means we're still providing a good user experience, with prioritized content being loaded first, and content of lesser priority being loaded in the background.

Let's change track now, and focus on viewing the same site on a mobile device—this time the iPhone 6 Plus.

We perform the same test again, but this time set Chrome to emulate an iPhone 6 Plus, then we should see this:

The real test though is in the number of requests made, amount of data transferred, and the time taken to load the page. This time around, our browser made 103 requests, with 1.8 MB transferred from the server and completed the total download in approximately 12 seconds:

Here, we can clearly see that to provide best user experience to its customers, Amazon has cleverly reduced the page size and the number of requests.

We should constantly monitor our sites for performance; with CSS3 attributes being added or updated frequently, we can begin to update our site and start to remove dependencies on external libraries, which allows us to increase the speed of our site and ultimately provide a better user experience.

When developing responsive sites, we should check to see if our target browser or device can support a specific feature, rather than simply assuming it can be used.

For example, if we were to install the latest Chrome browser on an old Android phone, we might be tempted to assume that it will support the latest features, such as CSS animations, background parallax effects, and WebGL.

But, is this really the case? What would happen if we were to try to operate a site that relied on a feature that is not supported on an older Android device? The end result might be that our browser becomes unresponsive or crash; we would be forced to have to reboot it to restore service.

This issue was faced by Android users recently in a big way and in this the most noticeable application to suffer was Google Talk/Hangout. With their upgrade, the most lightweight chat service of Google was turned to an almost unusable application due to performance issues on the older devices.

This way it is really important to filter out those features, which are less usable and have less relevance on small screens. A great example is the applications that make use of proximity sensors. This helped push manufacturers to make this a standard feature across all newer smartphones.

We developed an eye-catching, responsive, animated, and touch-oriented website but for a user who has poor Internet connection or an old device?

What should we do if the site appears to be hanging during the initial load or on subsequent page refreshes?

The reader will of course be confused as to what they should do.

Here is a simple thing we should do. Ever run Gmail on an old device or slow Internet connection? If yes, then you must have noticed Load basic HTML (for slow connections), or even this gem, where slower connections mean we may be forced to use Gmail's simple view, because a slow Internet connection makes using the standard view impossible:

For the elite few who are used to high-speed cable or broadband connections, they may find it hard to believe that other users do not have that luxury, and are forced to use the basic view, as would be the case in our example. Using this option loads the basic GUI version of Gmail, which is optimized for slower connections, and allows the user to interact with the site.

This illustrates a great point—if a site must use the latest features, then we should consider implementing a basic or standard mode in our application. We progressed from the days of a select few sites that have all of the latest features and which get all of the traffic, providing a user with what they are looking for on the website is what they care about.

We should always follow the standard of either use it or keep it. It is difficult to keep track of all the libraries and modules which are in use; we have to strike a fine balance between the libraries we use and maintaining site speed.

Many frameworks and libraries now have the option to customize the functionality provided within; for example, we may only require key elements of jQuery (if we were using it); we can select to exclude redundant functionality when downloading the library. However, if we are still at a development phase, then we will require the whole library; we can choose the parts needed to run our application, before minifying it for production use.

The utopia for any designer is to have a 100% bug-free site; the reality though is that while this will always be at the back of the developer's mind, it is impossible to achieve!

Why? One key consideration is the use of CSS3 (and those elements of CSS4 that now exist); although support is constantly improving, there is still a way to go before every browser offers consistent support for all CSS3 attributes. In the same vein, support for responsive media and media queries are not supported by older browsers, so we must consider how much support we can afford to offer for these browsers.

Considering possible solutions, we've touched on three elements which are key considerations for responsive sites, to work around them, there are a number of options open to us.

We can (and should) consider constructing our site using the base content that will work on any browser; we can then progressively enhance the experience, by adding extra features that may only work for some browsers, but are not key to the overall user experience. In comparison, we could take the view that we build our site around the latest technologies and browsers, but then add in support to allow content to degrade gracefully, when used on older browsers.

Can we work around these issues? Absolutely, there are a number of different options on offer. There is one point we should consider though, using a JavaScript solution isn't necessarily the best solution; there are a number of tips and tricks we can use to help retain compatibility. Before we touch on these, let's take a moment to consider some of the options available when using JavaScript as a solution:

Although these solutions will work perfectly well, they all suffer from one inherent drawback—JavaScript! In this modern age, most browsers are likely to have this switched on by default, but there will be instances where this is not the case; let's explore why using JavaScript isn't always the right solution.

During the construction phase of any responsive site, we will naturally need to work out which breakpoints we want to support. This will be based on statistics such as Google Analytics. The normal route would then be to use media queries in our CSS style sheet to load elements when needed. This works fine for recent browsers (anything within the last year to eighteen months), but with older browsers this will prove an issue.

We can support them using JavaScript-based solutions:

Clearly these drawbacks make for a less attractive option when using JavaScript! Two key questions we should ask though are: do we really need to support older browsers, such as IE8, and use JavaScript to support them?

The question of which browsers to support is one that will divide both developers and designers; on one hand, we will have creatives that want to take advantage of the latest functionality, while others will state that we must support as wide a browser population as possible.

The latter might normally require the use of JavaScript for older browsers; given that this requires extra resources that we must call from the server, it makes sense to use CSS where possible. To this end, we can consider using the relatively new @supports feature, (or feature queries, to give it its technical name). This works in a similar way to media queries and allows us to style elements based on whether the chosen style is supported in the browser. This has gained great support in most recent browsers (except of course IE, which always likes to be different!):

We can then create code such as this in the main markup:

<article class="artwork"> 
  <img src="myimg.jpg" alt="cityscape"> 
</article> 

And style it using code such as this, when it is supported:

@supports (mix-blend-mode: overlay) { 
  .artwork img { 
    mix-blend-mode: overlay; 
  } 
} 

However if it isn't supported, then we simply add a feature query to allow it to gracefully degrade:

@supports not(mix-blend-mode: overlay) { 
  .artwork img { 
    opacity: 0.5; 
  } 
} 

The beauty of this is that we're not reliant on any external libraries to help support what might be core functionality; we can use this to support new CSS3 styles and existing properties. Granted, it means that our style code base will increase, but this is tempered as the increase is in an existing file that is already cached, than having to call an additional new resource from the server!

If we test our site on a device such as an iPhone 6, there is a good chance it will work as well on other Apple devices, such as iPads. The same can be said for testing on a mobile device such as a Samsung Galaxy S4; we can use this principle to help prioritize support for particular mobile devices, if they require more tweaks to be made than in comparison to other devices.

Ultimately though, we must use analytical software to determine who visits our site; the information such as browser, source, OS, and device used will help determine what our target audience should be. This does not mean we completely neglect other devices; we should try to ensure they work with our site too, but this will not be a priority during development.

A key point to note is that we should not attempt to support every device; this is too costly to manage, and we would never keep up with all of the devices available for sale! Instead, we can use our analytics software to determine which devices are being used by our visitors; we can then test a number of different properties:

Once we've determined which devices we should be supporting, then there are a range of tools available for us to use, to test browser compatibility. These include physical devices (ideal, but expensive to maintain), emulators, or online services (these can be commercial or free). Let's take a look at a selection of what is available, to help us with testing browser compatibility.

When we plan to test a mobile or responsive website, there are factors which we need to consider before we start testing, to help deliver a website which looks consistent across all the devices and browsers. These factors include answering these three questions:

To help test our sites, we can use any one of several tools available (either paid or free); a key point to note though, is that we can already get a good idea of how well our sites work, by simply using the Developer toolbar that is available in most browsers!

Granted, it's not something we should absolutely rely on, but it provides a perfect starting point. We can always move up to a commercial option when we've outgrown the capabilities offered in a browser. Let's take a brief look at what's available:

We can easily emulate a mobile device within Chrome, by pressing Ctrl + Shift + M ; Chrome displays a toolbar at the top of the window, which allows us to select different devices:

If we click on the menu entry (currently showing iPhone 6 Plus) and change it to Edit, we can add new devices; this allows us to set specific dimensions, user agent strings, and whether the device supports high-resolution images:

Let's switch now, and take a look at the options available in Firefox.

The responsive design view option is available using the same Ctrl + Shift + M option as Chrome; we can also access it by navigating to Tools | Web Developer | Responsive Design Mode from the menu.

When the mode is activated in Firefox, we can switch between different screen sizes:

Although browsers can go some way in providing an indication of how well our site works, they can only cater to a limited range of views. Sometimes, we need to take things a step further and use commercial solutions to test our sites across multiple browsers at the same time. Let's take a look at some of the options available commercially.

If you've spent any time developing code, then there is a good chance you may already be aware of Browserstack (from https://www.browserstack.com). Other options include the following:

If, however, all we need to do is check our site for its level of responsiveness, then we don't need to use paid options. There are a number of sites that allow us to check, without needing to install plugins or additional tools:

We can also use bookmarklets to check to see how well our sites work on different devices—a couple of examples to try are at http://codebomber.com/jquery/resizer and http://responsive.victorcoulon.fr/; it is worth noting that the current browsers already include this functionality, making the bookmarklets less attractive as an option.

You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

You can download the code files by following these steps:

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Responsive-Web-Design-with-HTML5-and-CSS3-Essentials. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/ResponsiveWebDesignwithHTML5andCSS3Essentials_ColorImages.pdf.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at copyright@packtpub.com with a link to the suspected pirated material.

We appreciate your help in protecting our authors and our ability to bring you valuable content.

If you have a problem with any aspect of this book, you can contact us at questions@packtpub.com, and we will do our best to address the problem.

A key part of RWD is working with the viewport or visible content area on a device. If we're working with desktops, then it is usually the resolution; this is not the case for mobile devices.

There is a temptation to reach for JavaScript (or a library such as jQuery) to set values such as viewport width or height, but there is no need, as we can do this using CSS:

<meta name="viewport" content="width=device-width"> 

or using this directive:

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

This means that the browser should render the width of the page to the same width as the browser window—if for example the latter is 480px, then the width of the page will be 480px. To see what a difference that not setting a viewport can have, take a look at this example screenshot:

This example was created from displaying some text in Chrome, in iPhone 6 Plus emulation mode, but without a viewport. Now, let's view the same text, but this time with a viewport directive set:

Even though this is a simple example, do you notice any difference? Yes, the title color has changed, but more importantly the width of our display has increased. This is all part of setting a viewport—browsers frequently assume we want to view content as if we're on a desktop PC. If we don't tell it that the viewport area has been shrunk in size (and that we have not set the scaling correctly), it will try to shoehorn all of the content into a smaller size. This will result in a page that will appear to be zoomed out, which doesn't work very well!

It's critical, therefore, that we set the right viewport for our design, and that we allow it to scale up or down in size, irrespective of the device. We will explore this in more detail, in Chapter 2, Creating Fluid Layouts.

When designing responsive sites, we can either create our own layout or use a grid system already created for use, such as Bootstrap. The key here though is ensuring that the mechanics of our layout sizes and spacing are set according to the content we want to display for our users, and that when the browser is resized in width, it realigns itself correctly.

For many developers, the standard unit of measure has been pixel values; a key part of responsive design is to make the switch to using percentage and em (or preferably rem) units. The latter scales better than standard pixels, although there is a certain leap of faith needed to get accustomed to working with the replacements!

Two key parts of our layout are of course images and text—the former though can give designers a bit of a headache, as it is not enough to simply use large images and set overflow—hidden to hide the parts that are not visible!

Images in a responsive site must be as flexible as the grid used to host them—for some, this may be a big issue if the site is very content heavy; now is a good time to consider if some of that content is no longer needed, and can be removed from the site. We can of course simply apply display: none to any image which shouldn't be displayed, according to the viewport set. However, this isn't a good idea though, as content still has to be downloaded before styles can be applied; it means we're downloading more than is necessary! Instead, we should assess the level of content, make sure it is fully optimized and then apply percentage values so it can be resized automatically to a suitable size when the browser viewport changes.

With content and media in place, we must turn our attention to media queries—there is a temptation to create queries that suit specific devices, but this can become a maintenance headache.

We can avoid the headache by designing queries based on where the content breaks rather than for specific devices—the trick to this is to start small and gradually enhance the experience, with the use of media queries:

<link rel="stylesheet" media="(max-device-width: 320px)" href="mobile.css" /> 
<link rel="stylesheet" media="(min-width: 1600px)" href="widescreen.css" /> 

We should aim for around 75 characters per line, to maintain an optimal length for our content.

Accessibility plays a key role in responsive design. Our content should be as intuitive as possible, with every single piece of information easy to access. Responsive design places great emphasis on making our design self-explanatory; there shouldn't be any doubt as to how to access information on the site.

Even though our mobile version may not contain the same information (which is perfectly accessible), it nonetheless must be engaging, with appealing colors, legible text (at all sizes), and a design that retains visual harmony and balance with our chosen color scheme.

The success of our site is determined by a host of factors, of which one of these will be how our content is organized in the layout. The content should be organized in such a way that its layout makes it easy to process, is simple and free of clutter, and that we're making full use of the available viewport space for the device we're targeting.

We must also ensure our content is concise—we should aim to get our point across in as few words as possible so that mobile users are not wasting time with downloading redundant content. Keeping our options simple is essential - if we make it too complicated, with lots of links or categories, then this will increase the time it takes for visitors to make decisions, and ultimately only serve to confuse them!

At this point, it is worth pointing out something - over time, you may come across the phrase adaptive design, when talking about responsive design. There is a subtle but key difference between the two, and either can be used as a principle when constructing our site. Let's take a moment to explore what each means, and the differences that might affect how we go about constructing our sites.

Although there are lots of tips and pointers we can use to help improve our responsive development, there is one subject that is worth exploring in more detail—touch.

Why? The answer is simple—working responsively is not just about writing code; anyone can write code. The difference though, and that which separates great developers from the crowd, is the thought given to how that site looks and works. Care paid at this point will separate exceptional sites from the also-rans; to get a feel for the kind of decisions and thoughts one might go through, let's take a look at what we might have to consider when designing for touch:

Source: The Next Web (http://www.thenextweb.com)

Hover stages are a no-no in responsive design—these do not exist. Any calls to action should be based around tapping, so make sure your design takes this factor into consideration.

Phew, there are a few things to think of there! The key thing though is that while writing code is easy, creating an effective responsive design takes time and resources, and should always be a continuous affair, so our designs can stay fresh and up to date.

It's time for us to move on to a different subject, now that we've explored some of the guidelines and tips we can use to help with responsive development, it's time for us to consider our workflow. We may already have an established one for producing standard sites, making a shift to incorporate responsive design may require us making some changes to our processes, so let's go and explore what a typical workflow could look like when working with responsive design.

This initial stage is the same for any sites, but is particularly important for responsive design, given the different viewport sizes we have to support in our site. It's all about getting to know the client and their requirements. We must get an understanding of our client's business, their competitors, and what they are trying to achieve.

It's at this point we should be asking questions such as, "Why would people come to your site?", "What is the main goal you are trying to achieve?", and "Who are your main competitors?" The more we ask, the more we can understand and therefore better advise our clients on the best solution to fit their requirements.

When we've gathered all of the knowledge needed to construct our site, we now need to plan how it will look. We can start with the initial concept, but rather than work on the layout as we might have done before, we should concentrate on the content elements, and creating user stories and the information architecture. We can then put this together in a rudimentary HTML wireframe. At this stage, layout is less critical; it's key that we get the right view of information, before focusing on where it sits on the page.

At this point, we now need to focus on writing our content in textual form. This often under-rated step is probably the most important of the whole process; without it, people won't come to see the site, and there is no point in designing a layout if we don't know what will fill it! A useful tip is to keep styling to a minimum and to concentrate on the content; at least initially, we can see how it will display in a long, continuous format, and if it works for those who use screen readers. Don't worry though, we can always refine the text during the prototyping stage; at this point, we need something to start with, but it will be unlikely we get it right first time.

For our next step, forget using PhotoShop; it takes forever and is a real pain to make corrections quickly! The agile process is about making quick and easy changes and there is no better medium than traditional pen and paper. We can even print off the plain text content and sketch around, it if that helps, it will save us hours of development time, and can even help reduce those occasions when you hit the developer's block of...what now?

With the design sketched, it's time to create a prototype. This is when we can see how the layout will respond to different viewport sizes and allow us to highlight any potential challenges, or react to any issues that are reported by our client. It's good to be aware of the various breakpoints, but ultimately we should let our content determine where these breakpoints should be set in our design.

We might be used to prototyping our design using PhotoShop, but a better alternative is to switch to using a browser. We can use a service such as Proto.io (https://proto.io/) or Froont (http://froont.com/). This gives us extra time to get the harder elements right, such as typography; it also helps to remove any constraints that we might have with tools such as PhotoShop.

Although we may still be at a prototype stage, it's important to introduce testing early on. The number of breakpoints we may end up having in our design means that testing on multiple devices will take time! As an alternative to running a big test and reveal, we can instead perform multiple tests and reveals. This has the benefit of reducing the impact of any rollbacks (if something doesn't fit requirements), but also helps to keep the client involved with the project, as they can see progress take place during development.

The one thing we absolutely must do is to test over multiple devices. It's an expensive proposition to maintain a test suite with these devices, so it's worth asking colleagues, friends, and family to see if they can help test for you. They can at least browse the site and help pinpoint where things don't look right (to use customer parlance). It's up to us to work out where the root cause is, and implement a fix to help improve the user experience.

You will notice that I italicized the word experience at the start of this section—the key point here is that in responsive design, the experience does not have to be identical across all devices; it must be useful though, and allow our visitors to interact with us as an organization. In other words, if we worked for a theater, we might limit our mobile offer to simply booking tickets, and let the main desktop site manage everything else.

This is perfectly valid; while limiting a site, mobile ticketing might be considered by some as very restrictive. The concept is still technically sound, as long as the user experience is acceptable.

It's worth noting that we could have set a specific width using width=<value>. This is great if we need a certain width to display our content; if the orientation changes from portrait (320px) to landscape (360px) for example, then the viewport's content will be automatically scaled up and down to reflect these changes. If, however, we had set a device-width as a maximum, this implies that no scaling is need and that the browser should adjust the content within it to fit.

A key part of responsive design is to make the move away from using pixel values to working with em or rem units. In our examples (and the viewport demo from earlier in this chapter), we used both pixel and rem units. Although this works well, we still have a dependency on parent elements. Instead, we should consider using an alternative for working with viewports. They are:

As a unit of measure, these equate to 1% of the viewport area that has been set; the beauty though is that they remove any dependency elements, and are calculated based on the current viewport size. Browser support for them is currently very good:

Source: http://caniuse.com/#search=vh

Leaving aside the slight quirks with more recent versions of Internet Explorer, this is a useful option that combines the ease of units, with the flexibility of using percentages, in our designs.

Let’s move on—we’ve introduced flexible grids and explored how setting a viewport is critical to displaying content correctly. It’s time we moved on and explore some of the benefits of incorporating a grid system into our layout, and dive into the internals of how they work as a principle in responsive design.

Taking a closer look at our code, we will find that a large part of it uses standard attributes, which we might find on any site. The code that is of interest to us starts on line 50; to understand its role, we first need to get our heads around the basic concept of flex layouts:

Source: W3C

In a nutshell, items are laid out following either the main axis (from main-start to main-end) or the cross axis (from cross-start to cross-end):

With this in mind, let's explore some of the flexbox terms that have been used in our code; the initial few styles are standard rules that could apply to any site. The code of interest to us starts on line 29.

If we scroll down to that line, we are met with this:

Our first attribute, display: flex, defines the container which contains the flex items; here, we're setting it to show items in rows, and to wrap from left to right. If we had a number of columns in our layout, and by this I mean more than just two or three, then we might use align-items and justify-content to ensure that each column was evenly spread throughout the row, irrespective of the width of each column.

With the .grid defined, we need to style our grid-cells, or the containers where we host our content. There are several properties we can apply; the one we've used is flex, which is shorthand for flex-grow, flex-shrink, and flex-basis. In our case, it is recommended that the shorthand version be used, as this will set the other values automatically; we've set flex-grow to 1, which indicates how much it should grow, in relation to other flexible items in the same container.

The next property of interest is in the .nav rule. Here, we've used flex-flow again, but this time we also justify-content; the latter controls how items are packed on each row (in this case, toward the end of the line):

Our last block of code of particular interest is this section, within the large screen media query:

The order property simply specifies the order of each item in our flex container; in this case, we have .aside-1 and .aside-2 in position 1 and 2 respectively (not in shot), with the .main in the middle at position 2.

Let's move on. We've explored some examples of what is possible now, but there is at least one downside with using flexbox. The technology works very well, but can add a fair amount of code and complexity when implementing in a site.

It's time to look for something simpler to use, which doesn't require quite the same effort to implement; enter CSS grid templates! This is still an early technology, with minimal browser support, but is already easier to implement. Let's dive in and take a look in more detail.

For our next demo, we're going to make use of an example created by the developer Rachel Andrew, at http://codepen.io/rachelandrew/full/LGpONE/; we'll be replacing the images with ones from Flickr, depicting pictures of my favorite European town, Bruges. No, it's not to do with the lace, before you ask: good food, fine wine, great atmosphere, stunning chocolates for sale...what more could you ask for, I wonder?

But I digress. Before we get into creating our code, there are a couple of points we must bear in mind:

Without further ado, let's make a start on our demo:

Okay, granted. It's probably not what you might expect in terms of styling, but this demo isn't about making it look pretty, but the basic grid effect. There are nonetheless some important concepts that are good to understand, so let's dive in and explore what took place in our demo in more detail.

Earlier in this chapter, we explored how flexbox can be used to create a grid layout; if we were to compare CSS styling, it is easy to see that on balance, we need to provide more styling when using flexbox than using CSS Grid Layout.

The only styling attribute that we've used in our core styles is box-sizing, which we set to border-box. Nothing else has been used at this point—all of our CSS Grid Layout styles have been set within two media queries.

Our first media query sets the .wrapper class as our grid container. Note that we've only need to set it once, as it will cascade through to larger viewports that are 500px or greater in size.

Once the grid container is assigned, we then specify the grid columns for our template - the 1fr value assigned represents the fraction of free white space in the grid around each cell's content (hence the fr unit). We then finish up by specifying grid-row or grid-column in both media queries - these values define a grid item's location within the grid; these two terms are shorthand for grid-row-start, grid-row-end, grid-column-start and grid-column-end respectively.

To embed those videos, we need to use iframes, which unfortunately do not maintain aspect ratio by default; we can work around this with a CSS solution by Thierry Koblentz.

Let's for argument's sake say that we have a YouTube video, such as this one, titled The Big Buck Bunny, by the Blender Foundation:

(c) Blender Foundation | www.bigbuckbunny.org

Looks okay, doesn't it? Granted, we can't immediately tell it is a video from YouTube, but this next screenshot clearly shows it is:

Hold on; that doesn't look right, does it? The screenshot was taken in Google, but set to emulate the screen estate of a Galaxy S5 mobile phone, but it clearly shows that the video is not responsive.

To see this in action, extract a copy of youtube.html from the code download that accompanies this book to our project area, then run it in a browser. Activate your browser's responsive mode (or device mode, depending on browser) and resize the screen to 360px by 640px. You will soon see how it doesn't resize well!

How do we fix this?

The trick is to create a box with a proper aspect ratio, say 4:3 or 16:9 (through zero height and bottom padding in %), and then fit the video and stretch it inside the box up to the box dimensions by positioning it absolutely with respect to the box. The bottom padding acts as the width that helps to maintain the aspect ratio. Let's alter our code to fix this issue:

This looks much better! With some simple styling, we have the best of both worlds; we can let YouTube do all the heavy lifting while we concentrate on making our video available from our site on multiple devices. The CSS we used forces all of the video content to the full width of the .video-box-wrapper container, which in turn is positioned relative to its normal position. We then add 56.25% to the bottom to maintain the classic 16:9 aspect ratio and provide a little extra padding at the top so it doesn't appear to go off screen!

There will be occasions, though, when we have to host our own videos; this might be for controlling visibility or preventing adverts from being played, if we were to host it externally. To achieve this, we can use the now current HTML5 <video> element to render content on a page; let's take a look and see how this works in action.

If hosting videos on an external source is not possible, then we must host locally; for this, we can use the native HTML5 video tag, which looks something like this:

<video controls> 
  <source src="video/bigbuckbunny.webm" type="video/webm"> 
  <source src="video/bigbuckbunny.mp4" type="video/mp4">  
</video> 

In the past, codec support for the HTML5 element has been split across each platform; in 2015, Firefox added support for H.264 to its browsers across all platforms, which goes a long way to rationalize support for HTML5 video. At present, support for the two formats (MP4 and WebM) is good, but not 100% across all browsers – this screenshot indicates the current state of play for desktop and mobile browsers for the MP4 format:

Source: CanIuse.com

In contrast, support for the WebM format is not quite so complete:

Source: CanIuse.com

In reality, the only format we need to worry about using is MP4; we can use WebM format if desired. If we do so, then it must come first in the <source> list; otherwise, the browser will pick the first available supported format (in this case, MP4) and not use WebM!

Now that we've been introduced, let's move on and put it into practice, with a simple demo to illustrate how the <video> element works in action.

If our requirements are such that we have to host a video ourselves, then implementing it using the HTML5 standard tags is very easy; it consists of setting any number of different sources within the <video> tags so that we can play the same video using the supported format for that browser. Let's dive in and take a look at how we do it:

The result looks perfect—the question is, which version of our video is being used? One way to find out is to right-click on the video, while it is still playing, then click on Save video as.... If all is well, we should see a Save As dialog box open, ready to save the WebM format if we're using FireFox, Chrome, or Opera; otherwise it will be MP4 (if using IE).

<video controls> 
    <source src="video/bigbuckbunny.webm" type="video/webm"> 
    <source src="video/bigbuckbunny.mp4" type="video/mp4"> 
</video> 

video { 
   max-width: 100%; 
   /* just in case, to force correct aspect ratio */ 
   height: auto !important; 
} 

If you spend any time on the Internet, it's possible you've come across sites where the developer hasn't used images as a background, but video.

This isn't entirely new as a concept; it's been around for a couple of years now. If done with care, it can work very well. It's a perfect candidate for making full-size video as a responsive background. The great thing about it is that we can make it responsive using pure CSS. That's right, no need for any JavaScript.

For our next demo, we'll take a break from creating content. This time around, we'll run the demo from the code download that accompanies this book, and take a look at the code in more detail later in the demo. We'll be using videos from the Big Buck Bunny project, created by the Blender Foundation as our background; over this, we'll overlay a simple block of sample text, generated using the Lorem Ipsum generator.

To see this in action, go ahead and run the fullscreen .html demo from a copy of the code download that accompanies this book. If all is well, you will see the video play behind a simple <div> with text:

If we take a look at our code in more detail, we can see the video element in use; it's been set to autoplay, with sound muted and a poster (or placeholder) image set. The real magic, though, lies in the CSS styling, so let's explore this in more detail.

Exploring what happened

The trick that makes our video work is in this code. We need to set two media queries with 16:9 aspect ratio (one as a min-aspect-ratio, another as the max) so that our video displays correctly on the screen:

When resizing it though, it will show white space. We fix that by setting negative margins, which makes the viewport much wider, and allows us to center the content on screen:

A key point to note is the values used for height, top, left, and width; although these seem extreme, they are required to help center the video on screen when viewing the content with a 16/9 aspect ratio set.

Perfect! Our video plays well. We can see the content without too much difficulty. Everything should be good, surely? Well, yes and no; concepts such as background video are not without their risks; it's important to understand where things might fall over if we're not careful. Let's pause for a moment and consider some of the potential traps that might upset the proverbial apple cart, if we're not careful with our video.

In our previous example, we explored the concept of adding video as background content. It's a fashion that has taken off within the last couple of years, and provides an interesting effect, that is different to seeing the standard images we might otherwise see!

It's not without a certain element of risk though; there are a few pointers we must consider, when adding video as the background content:

Even though we have some clear pointers that should be considered, it should not stop us from using this effect; I'm one for pushing out the boundaries of what is possible, provided we do it well!

Question—we've worked on making videos responsive, but what about audio content?

Well, we can apply similar principles to the HTML5 <audio> element; instead of setting a specific width, we can use max-width and set a percentage figure to control how wide it displays on the screen.

The code to achieve this is very simple, and should by now be familiar—let's take a look at what is involved:

At first glance, it may not look special, but then the <audio> element isn't meant to look anything out of the ordinary! The key here though is when we resize the browser window; we've set a max width value of 100%, but have constrained this by setting an upper limit of 50rem in the width attribute. No matter how many times we resize our window, the audio player will fill the full width, but not go any wider than 50rem.

Let's move on and put our new-found knowledge to the test to create a practical example—how about making a video fullscreen, and responding to changes in the browser viewport automatically? Setting up video using this technique is always fraught with controversy, but I'm not one to shy away from a challenge, so without further ado, let's dive in and see why we must step carefully when using video at fullscreen.

Throughout the course of this book, we've concentrated on using the core technologies of HTML5 and CSS3; in many cases, this is all we need, but there will come a time when we have to use other technologies to help fulfill a task, as we've outgrown the art of possible with plain CSS and HTML code.

Thankfully, there are lots of options available online to help with making videos responsive, and to take our skills. It goes without saying though that we should always ask ourselves if our need for another library is because the realities of life mean that we can't achieve our task without using it or if we've simply become too lazy!

If indeed we do need to download and use an additional library, there are a few good options to try out, which include:

A small word of caution—a number of the video plugin libraries for jQuery haven't been updated for some time; you may well find that they no longer work properly with more recent versions of jQuery. This isn't necessarily a bad thing, as support for the HTML5 <video> and <audio> elements is now excellent; this renders many of these libraries surplus to requirements!

Phew! We're almost through this part of the journey, but before we move onto taking a look at using media queries in the next chapter, there is one more part of making responsive content; how about the text we have on our sites? It might not immediately strike you as being one we would associate with videos and text (at least in the context of making content responsive), but all will shortly become clear.

When working on non-responsive sites, it's likely that sizes will be quoted in pixel values; it's a perfectly acceptable way of working. However, if we begin to make our sites responsive, then content won't resize well using pixel values; we have to use something else.

There are two alternatives: em or rem units. The former is based on setting a base font size that in most browsers defaults to 16px; in this example, the equivalent pixel sizes are given in the comments that follow each rule:

h1 { font-size: 2.4em; }      /* 38px */ 
p  { line-height: 1.4em; }    /* 22px */

Unfortunately, there is an inherent problem with using em units; if we nest elements, then font sizes will be compounded, as em units are calculated relative to its parent. For example, if the font size of a list element is set at 1.4em (22px), then the font size of a list item within a list becomes 30.8em (1.4 x 22px).

To work around these issues, we can use rem values as a replacement, these are calculated from the root element, in place of the parent element. If you look carefully throughout many of the demos created for this book, you will see rem units being used to define the sizes of elements in the demos.

The rem (or root em) unit is set to be relative to the root, instead of the parent; it means that we eliminate any issues with compounding at a stroke, as our reference point remains constant, and is not affected by other elements on the page.

The downside of this is support—rem units are not supported in IE7 or 8, so if we still have to support these browsers, then we must fall back to using pixel or em values instead. This of course raises the question: should we still support these browsers, or is their usage of our site so small as to not be worth the effort required to update our code?

If the answer is that we must support IE8 or below, then we can take a hybrid approach; we can set both pixel/em and rem values at the same time in our code:

.article-body { 
  font-size: 1.125rem;  /* 18 / 16 */ 
  font-size: 18px; 
} 
 
.caps, figure, footer { 
  font-size: 0.875rem;  /* 14 / 16 */ 
  font-size: 14px; 
} 

Notice how we set rem values first? Browsers that support rem units will use these first; the ones that don't can automatically fall back to using pixel or em values instead. The values in each comment are the pixel equivalents; if, for example, we divide 18px by 16px (as the base value for all sizes), we would arrive at 1.125, as indicated in the text.

If we want to take it further, then there is another alternative we can explore; how about using viewport units?

These effectively combine the best of both worlds; a viewport unit (or 1vw) is 1% of the viewport axis. So, if we had a viewport of 50 cm wide, a single vw unit would be 0.5 cm. We can specify sizes in the same way as we would do for pixel, em, or rem units. Take a look at this little extract, which gives a flavor of what it would look like:

h1 { font-size: 5.9vw; } 
h2 { font-size: 3.0vh; } 
p { font-size: 2vmin; } 

The beauty though is no matter what size the viewport, the font size will always appear correctly, as it will automatically resize if the view port is changed.

Okay, at this point, we've added responsive capabilities to our text; our sites are looking pretty good....I can see a but coming....

At present, support for responsive text (and in particular vw or rem units) is excellent; browsers that will choke on these two units are few and far between. However, there may come a time when we need additional help; unlike images or video content, there are not many options available to choose from! The two best examples are FlowType.js, available from http://simplefocus.com/flowtype/, and FitText.js, from http://fittextjs.com/.

The catch though is that these libraries haven't been updated for 2-3 years, so are not likely to work with recent versions of jQuery. It's a good indicator of how well responsive text has come along over the years, and that we really should be using it natively, rather than relying on JavaScript!

If we take a look at the example query in the previous section, we see that part of it is made up of the type of media in use. This is just part of the query. All media queries come in two parts, with the first part controlling how our CSS will be displayed, with the second part taking care of when it is displayed.

Take a look at this example:

<!-- CSS media query on a link element --> 
<link rel="stylesheet" media="(max-width: 800px)" href="example.css" /> 
 
<!-- CSS media query within a stylesheet --> 
<style> 
@media (max-width: 757px) { 
  .sidebar { 
    display: none; 
  } 
} 
</style> 

This illustrates two ways of referencing media queries: the first example doesn't specify the media type, so we can infer it will be all by default; the second part of it states that it will only apply when the width of our window is at least 800px.

The second media query one doesn't specify the media type either, so again all will be inferred as the default; this time, the .sidebar element will not be displayed if the window width is less than 600px wide.

Let's see what all media types can be used:

In addition, to this, we have a number of features that we can use to control the trigger for displaying the content; it's worth getting to know them, as they all play an important role, but work in different ways. Let's take a look at the list in more detail and learn what each of them does in turn.

Adding a query that specifies the media target is only half the picture; we also need to give it something that controls when to display it! To achieve this, we can provide one or more conditions that must be satisfied in order for content to be styled or displayed.

Let's have a look at some of the options available:

The key here is selecting the right attribute against which we should run our test; a great example is checking orientation so that we can determine if a tablet is in portrait or landscape mode. We will make good use of some of these query tests later in this chapter.

Okay, time to move on. The theme so far has been what we can achieve by just using a browser and a text editor. This may seem limiting at first, but I maintain that too many people resort to using additional help (such as using jQuery) to create queries when it isn't always necessary to do so. In the main this will work, but there are some points that we should consider:

Okay, let's move on: it's time to get physical, and stuck into something more practical! We've covered some of the different facets that make up queries and explored some of the considerations we need to allow for, when working with just a browser and text editor. Before we get too practical though, we need to cover one more topic. There are occasions when we need to test for multiple conditions. We can do this using logical operators. Let's take a quick look at some of these in more detail.

When composing media queries that require multiple tests, we can make use of logical operators to confirm if one or more CSS rules should be applied to our content. If we use logical operators, we need to encapsulate each attribute that is tested in parentheses; otherwise, it will generate an error in our code.

Let's take a look at some of the more common examples of operators:

So far, we've talked about the basics of what a media query looks like: let's explore how we can use them to manage content by identifying where our designs break at different screen sizes. These breaks, or breakpoints,are what make media queries work – whilst it is clearly key that we get them right, it is also important to know when we should and should not use them...

The media queries we've already outlined should cover a wide range of scenarios; there will be occasions when these won't suffice, and our site isn't working as expected.

What do we do? Well, we are not limited to using the standard queries we've already covered; we can absolutely create our own!

Creating a custom breakpoint is very easy, as long as we do it the right way; done incorrectly, and we can create unnecessary breaks that have a limited use or an unintended knock-on effect to other devices. To see what we mean, let's work through a (theoretical) example.

Imagine your site has been resized to around 335px, and we see it is a little out of kilter—there are a number of elements that don't quite fit properly. To better manage content at this breakpoint, the temptation would be to write a query such as this:

@media only screen and (max-device-width: 345px){ 
  /* Styles */ 
} 

We would add our changes in the area headed by /*Styles*/.

Sounds reasonable, right? It would be, if it weren't for one thing: we've now just created a whole new set of problems for viewing devices that have a width lower than 345px!

The key to solving this issue is to not simply use a bigger pixel value, as this may break the layout for other devices—this includes mobile devices, in portrait or landscape modes. The right way to fix this is to identify the exact circumstances where our query fails, and to either adjust the query to better match the circumstances or (ideally) work out if the design itself can be tweaked to avoid the need for a query.

So, for example, if our site broke between 325px and 345px, and that the failure was in portrait mode only, we would create a media query such as this one:

@media only screen and (min-device-width : 325px) and (max-device-width : 345px) and (orientation : portrait) { 
  /* Styles */ 
} 

How does this help us? Well, refining our query to be more explicit avoids any possible conflict with more generic queries that we might have already created. We're also making the threshold limits clearer too; we won't trigger the query unless we can match all three conditions at the same time.

Some developers may ask why we simply don't just fix the available viewport; this changes size when we change orientation, so surely the content will adjust to fit, right?

Well, yes and no. It's all about understanding where content is positioned, and the types of devices we want to support, in addition to desktops. We should not forget that it is perfectly valid to have a layout that is different in portrait mode to those in landscape; try looking at Packt's site in landscape and portrait modes on an iPad!

At the time of writing, an extra element is displayed in portrait mode, but it is not present in landscape orientation. If one of the elements in the portrait mode was broken and not displaying correctly, then simply specifying numerical breakpoints will not work. To fix the issue, we must also specify the affected orientation, otherwise fixing one mode may break another.

Okay, so we've created a bunch of media queries, ready for implementing into a site. We're good to move on and start building some examples, or are we? If I said to hold fire for a moment, you would very likely think I've lost my marbles; but as always, there is a good reason. Let me explain.

A drawback when using media queries is that no two sites will be the same; this means that we can't always reuse standard queries in multiple sites. There will be times when we have to create custom breakpoints to satisfy a requirement for a site; the trick is to know when and where our site may need extra attention, over and above the normal breakpoints we might have used in our site.

Creating custom, ad hoc queries is easy, but we do run the risk of creating too many, which undermines the whole concept of responsive design. Can we get around this? Well, yes we can; it involves a shift in our approach to designing, which is not to focus on viewport sizes, but our content instead.

Up until now, we've covered how we can use breakpoints to control what is displayed, and when, according to which device is being used. Let's assume you're working on a project for a client and have created a series of queries that use values such as 320px, 480px, 768px, and 1024px to cover support for a good range of devices.

No matter what our design looks like, we will always be faced with two issues if we focus on using specific screen viewports as the basis for controlling our designs:

So, hold on. We've created breakpoints, yet this can end up causing us more problems? If we're finding ourselves creating lots of media queries that address specific problems (in addition to standard ones), then we will start to lose the benefits of a responsive site; instead we should re-examine our site to understand why the design isn't working and see if we can't tweak it so as to remove the need for the custom query.

Ultimately, our site and target devices will dictate what is required—a good rule of thumb is if we are creating more custom queries than a standard bunch of four to six breakpoints, then perhaps it is time to recheck our design!

As an alternative to working with specific screen sizes, there is a different approach we can take, which is to follow the principle of adaptive design and not responsive design. Instead of simply specifying a number of fixed screen sizes (such as for the iPhone 6 Plus or a Samsung Galaxy unit), we build our designs around the point at which the design begins to fail.

Why? The answer is simple. The idea here is to come up with different bands, where designs will work between a lower and upper value, instead of simply specifying a query that checks for fixed screen sizes that are lower or above certain values. Don't worry for now if it doesn't entirely make sense just yet; for now, the key here is that we're creating designs that mean we can reduce the need to support so many devices.

Let's put this theory into practice, and start creating some demos to show off how we can use media queries in practice.

Making it real—what a title! There is a good reason for it. When exploring new concepts, one of my pet hates is exploring a demo that is so minimalistic as to not include anything that gives a true picture of the functionality that I want to begin using in my development.

Creating media queries should not be an exception. In our previous example, we created some test queries to see how three boxes would interact when the browser window is resized. To put this into context though, requires something a little more in-depth; one could do worse than explore how we might add similar queries to a portfolio page that might be part of a new or existing site. For our second demo, we're going to create a simple web page template, then begin to add and develop queries that allow it to be used on mobile devices.

Let's make a start:

A perfectly presentable page, I hope you will agree. It shows off two of my favorite things perfectly: my love of coffee and the Scrabble board game! I always say coffee must be the secret tool in many developers' armories, but I digress…

Try resizing the screen; for argument's sake, let's resize it to 414 x 736, or the equivalent required for an iPhone 6 Plus:

We can use Chrome's device mode to switch the orientation to landscape:

We can see that the site realigns itself:

It's a simple, clean design. The key here is that we can use this as a basis for adding more queries that support other devices. There are some important concepts that we should explore in more detail, so let's take five for a moment, and see how media queries play their part in our demo.

Exploring what happened

Many of the styles used in this example cater for styling our page; the key rules for us start on lines 33 and 50, where we style for an iPhone 6 Plus in portrait and landscape modes, respectively. Let's take a look at these two rules in more detail:

@media screen and (max-width: 414px) and (orientation: portrait) { 
... 
} 

This rule states that the screen width must have a max-width of 414px or less; if it is bigger and still showing in portrait mode, then the rule will not apply.

Within this rule, we've taken styles already used in the main block and applied changes that allow us to maintain the desired effect when viewing the site on an iPhone. A perfect example is the #banner block; in the main set of styles, we set a number of attributes to position it on screen:

#banner { float: left; margin-bottom: 0.9375rem; width: 100%; } 
#banner { height: 15rem; width: 44.5rem; background-image: url('../img/coffeebeans.png');  max-width: 100%; } 

However, that won't suit being displayed on an iPhone, leaving aside how big the image is at 717px by 214px. It also weighs in at a hefty 102KB! Clearly, we don't want to keep downloading such a large image on a mobile device (where Internet access is likely to be metered), so we need to do something else.

Instead, we have a smaller version in use, in the form of coffeebeans-small.png. This one is a more palatable 33KB, and sits in the top-right corner of our page when viewed on a mobile in portrait mode. We hide the original as it is not needed:

@media screen and (max-width: 414px) and (orientation: portrait) { 
... 
  #wrapper > header > img { float: right; display: block; } 
... 
  #banner { display: none; } 
} 

As soon as we flip to using it in landscape mode, this rule kicks in:

@media screen and (max-width: 736px) and (orientation: landscape) { 
... 
  #wrapper > header > img { float: right; display: block; } 
... 
  #banner { display: none; } 
} 

Notice though we don't need to change the rule. The image stays the same size and is already set to float to the right, so the rule can simply be reused. We have to specify it here too; otherwise, it won't display at all. To see the difference, try setting the demo using Google Chrome to emulate iPad mode:

We can see that even though the base code uses coffeebeans-small.png in the #banner <div>, our media queries have replaced it with coffeebeans.png.

Tip

You may notice that the media query widths are not set in rem units; this is purely so we can match them with the Device tool in Chrome. You can easily set them to rem units if you prefer to do so.

We've purposely kept the rules in our demo simple; they illustrate how, with little effort, we can get our page to display properly in both desktop, iPhone 6 portrait and iPhone 6 landscape modes perfectly. We can then reuse the same principles to extend support to cover other devices; the trick is to make sure that we use a breakpoint that covers enough devices so that we don't have to add more than is necessary to our site.

Let's change tack now, but stay with the Apple theme. No, I'm not thinking of food! How many of you are lucky enough to own an iPad? If the answer is yes, then this next demo will be of interest. For many standard devices, we are limited in terms of what resolution we can use when displaying images.

Enter a great trick. How about the ability to display higher-resolution images? We don't need to download anything to help with this. Most modern browsers can do this out of the box; all we need is the appropriate media query to tell browsers when to use them.

The advent (and some may say meteoric rise) of mobile devices has introduced an opportunity, supporting higher resolution images.

Most users can't distinguish individual pixels on standard PCs. When viewed at typical distances, some websites would appear too small to use! Instead, the PC will revert to a more realistic resolution, such as 1,440px.

To give a smoother view, some devices pack in extra pixels; this has the effect of making individual pixels harder to view, and images super crisp in appearance. This was started by Apple, who marketed them as Retina displays; others have begun to follow suit and create devices capable of supporting high-res images.

Thankfully, we don't need expensive iPhones or iPads to add support. We can do this with a media query and use Chrome's Device tool to simulate testing it. To see how, let's create a simple demo that switches between two images of a Phalaenopsis or Moth orchid plant. To tell which image is displayed, each will show the resolution in the top right corner of the image:

There are two points of note here—one is the setting on the left (Responsive), while the other is DPR or device pixel ratio. To trigger displaying the higher resolution image, try changing the setting on the left to iPhone 6 Plus:

Notice how the DPR setting has jumped to 3.0, and that our image has changed:

Hopefully, you will agree that this is a simple way to add support. Using Chrome, we can get a good representation of how a high-res image will appear; it is worth noting that it should still be tested on a proper device, as even Google can't entirely emulate specific devices from within their browser!

Exploring how it works

At this point, I am sure you will be asking how this all works. It's a simple trick. The key to it is the naming convention we used for the images at the beginning of the demo.

Remember how I said they should be saved as they are from the code download, and to not change the names? The reason for this is that we make use of this in our demo. Apple devices (since iOS4) expect to see the @2x in the filenames to denote a high-res image:

We then make use of that with our media query, which is only set to display the higher resolution image, if our min-resolution was detected to be 120dpi or greater.

Note

As an aside, you may see min/max-device-pixel-ratio being used. This is required to support recent versions of Safari. All other browsers can use min-resolution without issue, although not all support the dppi or dpcm unit formats that can also be used.

The power of media queries means we can tailor support for higher resolution images to those devices that can support them; if the device is not able to do so, then standard resolution images can be displayed instead.

Okay, let's change tack now. Although writing media queries is a straightforward task, there may be instances where even the best developer doesn't get it quite right! This could be anything from missing the viewport tag to inadvertently writing queries that clash with each other. Let's take a moment to explore some of the more common points where we might trip up, and take a look at a few pointers to help get us back on track.

Analysis shows that if a page takes longer than 4–5 seconds to load, then customers will frequently vote with their feet (that is, walk away). Any delay of more than a second can equally lead to a poor user experience.

A great source that can help us understand where some of our issues are is that behemoth, Google. We may knock it for being omnipotent, but it clearly knows some useful tricks!

Google states that our page doesn't have to entirely load within 4–5 seconds, but should be usable within this time; any content that is of a lower priority can be put below the fold or loaded in the background.

At a basic level, Google recommends that our server response time should be less than 200 ms—we should also explore aspects such as client-side rendering to help reduce the time taken to load our content:

Although much of this applies to any site, this is particularly important for responsive sites, given the extra code required to manage the experience for mobile devices.

Google also recommends that we should consider performing these tasks:

In addition, we can explore the use of other tricks to help with performance. These include the following:

If we want to explore things further, then there are some more advanced, invasive changes we can use to help optimize our site. These involve more work, so should be planned as longer term changes:

It takes time to optimize a site, but the effort spent in refining it will pay dividends in increased patronage and ultimately increased sales. The trouble is, we won't know how well our site performs unless we test it; let's explore some of the tools we can use to help gauge how well our site is operating, in more detail.

For our test, we'll start with a desktop browser—we'll use Google's Chrome as it has a good set of tools; other browsers can also be used, but you may not get quite the same results. Let's make a start, using Amazon as the basis for our test:

Here's what we need to do:

At this point, we will have a set of results we can browse through, similar to this extract:

At first, these results may not make sense, but the details we want are at the foot of the window.

This shows the number of server requests made, the amount of content transferred, and the times taken to initially parse the DOM (DOMContentLoaded); then, fully download the content (indicated by Finish and the Load event being fired).

Even though Amazon's site downloads a reasonable amount of content, they've made good use of some of the tricks we've covered, to help reduce bandwidth usage and increase page rendering speed. How can we tell? Try clicking on the bottom two links shown in the screenshot (or links 4 and 5 in the asset list shown within the browser).

The first link shows a minified CSS style sheet; if we look at it in more detail, it is possible to surmise that some of the links within were generated using an automated process. The PNG filename in one example is over 70+ characters long! The use of long names will increase the file size of the file concerned; images need to be accurately named, but with sensible filename lengths!

Considering the size of the page and the number of requests, it is possible to think that this website faces performance issues. However, if we look more carefully, we can see a lot of content is being loaded in the background. This means we're still providing a good user experience, with prioritized content being loaded first, and content of lesser priority being loaded in the background.

Let's change track now, and focus on viewing the same site on a mobile device—this time the iPhone 6 Plus.

We perform the same test again, but this time set Chrome to emulate an iPhone 6 Plus, then we should see this:

The real test though is in the number of requests made, amount of data transferred, and the time taken to load the page. This time around, our browser made 103 requests, with 1.8 MB transferred from the server and completed the total download in approximately 12 seconds:

Here, we can clearly see that to provide best user experience to its customers, Amazon has cleverly reduced the page size and the number of requests.

We should constantly monitor our sites for performance; with CSS3 attributes being added or updated frequently, we can begin to update our site and start to remove dependencies on external libraries, which allows us to increase the speed of our site and ultimately provide a better user experience.

When developing responsive sites, we should check to see if our target browser or device can support a specific feature, rather than simply assuming it can be used.

For example, if we were to install the latest Chrome browser on an old Android phone, we might be tempted to assume that it will support the latest features, such as CSS animations, background parallax effects, and WebGL.

But, is this really the case? What would happen if we were to try to operate a site that relied on a feature that is not supported on an older Android device? The end result might be that our browser becomes unresponsive or crash; we would be forced to have to reboot it to restore service.

This issue was faced by Android users recently in a big way and in this the most noticeable application to suffer was Google Talk/Hangout. With their upgrade, the most lightweight chat service of Google was turned to an almost unusable application due to performance issues on the older devices.

This way it is really important to filter out those features, which are less usable and have less relevance on small screens. A great example is the applications that make use of proximity sensors. This helped push manufacturers to make this a standard feature across all newer smartphones.

We developed an eye-catching, responsive, animated, and touch-oriented website but for a user who has poor Internet connection or an old device?

What should we do if the site appears to be hanging during the initial load or on subsequent page refreshes?

The reader will of course be confused as to what they should do.

Here is a simple thing we should do. Ever run Gmail on an old device or slow Internet connection? If yes, then you must have noticed Load basic HTML (for slow connections), or even this gem, where slower connections mean we may be forced to use Gmail's simple view, because a slow Internet connection makes using the standard view impossible:

For the elite few who are used to high-speed cable or broadband connections, they may find it hard to believe that other users do not have that luxury, and are forced to use the basic view, as would be the case in our example. Using this option loads the basic GUI version of Gmail, which is optimized for slower connections, and allows the user to interact with the site.

This illustrates a great point—if a site must use the latest features, then we should consider implementing a basic or standard mode in our application. We progressed from the days of a select few sites that have all of the latest features and which get all of the traffic, providing a user with what they are looking for on the website is what they care about.

We should always follow the standard of either use it or keep it. It is difficult to keep track of all the libraries and modules which are in use; we have to strike a fine balance between the libraries we use and maintaining site speed.

Many frameworks and libraries now have the option to customize the functionality provided within; for example, we may only require key elements of jQuery (if we were using it); we can select to exclude redundant functionality when downloading the library. However, if we are still at a development phase, then we will require the whole library; we can choose the parts needed to run our application, before minifying it for production use.

The utopia for any designer is to have a 100% bug-free site; the reality though is that while this will always be at the back of the developer's mind, it is impossible to achieve!

Why? One key consideration is the use of CSS3 (and those elements of CSS4 that now exist); although support is constantly improving, there is still a way to go before every browser offers consistent support for all CSS3 attributes. In the same vein, support for responsive media and media queries are not supported by older browsers, so we must consider how much support we can afford to offer for these browsers.

Considering possible solutions, we've touched on three elements which are key considerations for responsive sites, to work around them, there are a number of options open to us.

We can (and should) consider constructing our site using the base content that will work on any browser; we can then progressively enhance the experience, by adding extra features that may only work for some browsers, but are not key to the overall user experience. In comparison, we could take the view that we build our site around the latest technologies and browsers, but then add in support to allow content to degrade gracefully, when used on older browsers.

Can we work around these issues? Absolutely, there are a number of different options on offer. There is one point we should consider though, using a JavaScript solution isn't necessarily the best solution; there are a number of tips and tricks we can use to help retain compatibility. Before we touch on these, let's take a moment to consider some of the options available when using JavaScript as a solution:

Although these solutions will work perfectly well, they all suffer from one inherent drawback—JavaScript! In this modern age, most browsers are likely to have this switched on by default, but there will be instances where this is not the case; let's explore why using JavaScript isn't always the right solution.

During the construction phase of any responsive site, we will naturally need to work out which breakpoints we want to support. This will be based on statistics such as Google Analytics. The normal route would then be to use media queries in our CSS style sheet to load elements when needed. This works fine for recent browsers (anything within the last year to eighteen months), but with older browsers this will prove an issue.

We can support them using JavaScript-based solutions:

Clearly these drawbacks make for a less attractive option when using JavaScript! Two key questions we should ask though are: do we really need to support older browsers, such as IE8, and use JavaScript to support them?

The question of which browsers to support is one that will divide both developers and designers; on one hand, we will have creatives that want to take advantage of the latest functionality, while others will state that we must support as wide a browser population as possible.

The latter might normally require the use of JavaScript for older browsers; given that this requires extra resources that we must call from the server, it makes sense to use CSS where possible. To this end, we can consider using the relatively new @supports feature, (or feature queries, to give it its technical name). This works in a similar way to media queries and allows us to style elements based on whether the chosen style is supported in the browser. This has gained great support in most recent browsers (except of course IE, which always likes to be different!):

We can then create code such as this in the main markup:

<article class="artwork"> 
  <img src="myimg.jpg" alt="cityscape"> 
</article> 

And style it using code such as this, when it is supported:

@supports (mix-blend-mode: overlay) { 
  .artwork img { 
    mix-blend-mode: overlay; 
  } 
} 

However if it isn't supported, then we simply add a feature query to allow it to gracefully degrade:

@supports not(mix-blend-mode: overlay) { 
  .artwork img { 
    opacity: 0.5; 
  } 
} 

The beauty of this is that we're not reliant on any external libraries to help support what might be core functionality; we can use this to support new CSS3 styles and existing properties. Granted, it means that our style code base will increase, but this is tempered as the increase is in an existing file that is already cached, than having to call an additional new resource from the server!

If we test our site on a device such as an iPhone 6, there is a good chance it will work as well on other Apple devices, such as iPads. The same can be said for testing on a mobile device such as a Samsung Galaxy S4; we can use this principle to help prioritize support for particular mobile devices, if they require more tweaks to be made than in comparison to other devices.

Ultimately though, we must use analytical software to determine who visits our site; the information such as browser, source, OS, and device used will help determine what our target audience should be. This does not mean we completely neglect other devices; we should try to ensure they work with our site too, but this will not be a priority during development.

A key point to note is that we should not attempt to support every device; this is too costly to manage, and we would never keep up with all of the devices available for sale! Instead, we can use our analytics software to determine which devices are being used by our visitors; we can then test a number of different properties:

Once we've determined which devices we should be supporting, then there are a range of tools available for us to use, to test browser compatibility. These include physical devices (ideal, but expensive to maintain), emulators, or online services (these can be commercial or free). Let's take a look at a selection of what is available, to help us with testing browser compatibility.

When we plan to test a mobile or responsive website, there are factors which we need to consider before we start testing, to help deliver a website which looks consistent across all the devices and browsers. These factors include answering these three questions:

To help test our sites, we can use any one of several tools available (either paid or free); a key point to note though, is that we can already get a good idea of how well our sites work, by simply using the Developer toolbar that is available in most browsers!

Granted, it's not something we should absolutely rely on, but it provides a perfect starting point. We can always move up to a commercial option when we've outgrown the capabilities offered in a browser. Let's take a brief look at what's available:

We can easily emulate a mobile device within Chrome, by pressing Ctrl + Shift + M ; Chrome displays a toolbar at the top of the window, which allows us to select different devices:

If we click on the menu entry (currently showing iPhone 6 Plus) and change it to Edit, we can add new devices; this allows us to set specific dimensions, user agent strings, and whether the device supports high-resolution images:

Let's switch now, and take a look at the options available in Firefox.

The responsive design view option is available using the same Ctrl + Shift + M option as Chrome; we can also access it by navigating to Tools | Web Developer | Responsive Design Mode from the menu.

When the mode is activated in Firefox, we can switch between different screen sizes:

Although browsers can go some way in providing an indication of how well our site works, they can only cater to a limited range of views. Sometimes, we need to take things a step further and use commercial solutions to test our sites across multiple browsers at the same time. Let's take a look at some of the options available commercially.

If you've spent any time developing code, then there is a good chance you may already be aware of Browserstack (from https://www.browserstack.com). Other options include the following:

If, however, all we need to do is check our site for its level of responsiveness, then we don't need to use paid options. There are a number of sites that allow us to check, without needing to install plugins or additional tools:

We can also use bookmarklets to check to see how well our sites work on different devices—a couple of examples to try are at http://codebomber.com/jquery/resizer and http://responsive.victorcoulon.fr/; it is worth noting that the current browsers already include this functionality, making the bookmarklets less attractive as an option.