You can download the example code files for all Packt books you have purchased 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.

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/2102_0234_ImageBundle.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 would 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 on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.

Piracy of copyright 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.

You can contact us at <questions@packtpub.com> if you are having a problem with any aspect of the book, and we will do our best to address it.

There are two ways we can write Sass-style CSS: the Sass syntax and the SCSS syntax.

.selector-a
    float: left

        .selector-b
            background: orange

.selector-a {
    float: left;
}

.selector-a, .selector-b {
    background: orange;
}

.selector-a {
    float: left;
}

.selector-a, .selector-b {
    background: orange;
}

.selector- {
    &a {
        float: left;
     }
    &a, &b {
        background: orange;
    }
}

.selector-a {
    float: left;
}

.selector-a, .selector-b {
    background: orange;
}

$brandBlue: #416e8e;

$brandBlue: #416e8e;
body {
    background: $brandBlue;
}

body {
   background: #416e8e;
}

$brandBlue: #416e8e;
$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

.selector-a {
    @include genericContainer;
}

.selector-a {
    padding: 10px;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px rgba(0, 0, 0, 0.3);
}

$brandBlue: #416e8e;
$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba($brandBlue, .3);
}

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba($brandBlue, .3);
}

.selector-a {
    padding: 10px;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px rgba(65, 110, 142, 0.3);
}

In our first mixin example, we didn't have any arguments. This is really not ideal because it doesn't allow us to use different values in the same properties. In reality, not using any arguments in a mixin isn't really any different than typing the same properties and values every time we need them. We are not really doing any DRY.

Arguments are the part(s) of a mixin in which you can put your own values depending on your needs. Arguments make a mixin worth creating.

In the mixin example mentioned earlier, let's add an argument:

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer($padding) {
    padding: $padding;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

The argument for padding allows us to set any value we want. We are not forced to have the padding as 10px every time.

This is how we set the value of the argument:

.selector-a {
    @include genericContainer(10px);
}

This compiles to the following:

.selector-a {
    padding: 10px;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px rgba(0, 0, 0, 0.3);
}

However, there's a potential problem with the argument; if we don't set a value for the padding, we're going to get an error when compiling.

So the solution here is to set a default value; if we don't define a value for padding for some reason, Sass is going to take that default value and use it when compiling without throwing an error.

Here's how we set a default value of an argument:

$brandBlue: #416e8e;$supportGray: #ccc;
@mixin genericContainer($padding: 8px) {
    padding: $padding;
    border: $brandBlue 1px solid;
    background: $supportGray;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

This is how we call the mixin, without declaring any padding value:

.selector-a {
    @include genericContainer;
}

The compiled CSS is as follows:

.selector-a {
    padding: 8px;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px rgba(0, 0, 0, 0.3);
}

@mixin genericContainer ($padding, $bdColor, $bgColor, $boxShdColor) {
    padding: $padding;
    border: $bdColor 1px solid;
    background: $bgColor;
    box-shadow: 1px 1px 1px $boxShdColor;
}

.selector-a {
    @include genericContainer(2%, $brandBlue, #ccc, black);
}

.selector-a {
    padding: 2%;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px #000000;
}

@mixin genericContainer ($padding: 5px, $bdColor: orange, $bgColor: #999, $boxShdColor: #333) {
    padding: $padding;
    border: $bdColor 1px solid;
    background: $bgColor;
    box-shadow: 1px 1px 1px $boxShdColor;
}

.selector-a {
    @include genericContainer(25px);
}

.selector-a {
    padding: 25px;
    border: orange 1px solid;
    background: #999999;
    box-shadow: 1px 1px 1px #333333;
}

.selector-a { @include genericContainer($bgColor: $brandBlue); }

Nesting in Sass is a perfect way to make our SCSS more readable. Just like in HTML where tags get nested based on their parent elements, Sass uses exactly the same structure.

Here's an example of two-level selector nesting for a navigation bar:

$brandBlue: #416e8e;nav {
    ul {
        display: flex;
        margin: 0;
        padding: 0;
        list-style: none;
    }

    li {
        margin: 5px;
        background: #000;
    }
    a {
        display: block;
        padding: 5px 15px;
        text-decoration: none;
        color: $brandBlue;
    }
}

Did you notice that I used the $brandBlue color variable again? The preceding SCSS for the navigation bar compiles to the following CSS:

nav ul {
    display: flex;
    margin: 0;
    padding: 0;
    list-style: none;
}
nav li {
    margin: 5px;
    background: #000;
}
nav a {
    display: block;
    padding: 5px 15px;
    text-decoration: none;
    color: #416e8e;
}

Partial files are SCSS files we create to house SCSS snippets. Partials allow us to modularize our files, for example, _variables.scss. Partials start with the underscore symbol (_) and end with the extension .scss. The underscore symbol tells the compiler that this file and its contents do not need to be compiled into a separate CSS file.

Partials are called using the @import directive, just like it is done in CSS. The main differences are that there's no need to specify the underscore symbol and the file extension.

Let's create a partial file and put these color variables in it. We're going to call this partial file, _variables.scss. The variables (snippets) in the _variables.scss partial are as follows:

$brandBlue: #416e8e;
$brandRed: #c03;
$brandYellow: #c90;

Let's then say that our main SCSS file is named styles.scss. We now have two files: styles.scss and _variables.scss.

We call _variables.scss into styles.scss using the @import directive:

@import "variables";

Notice that the underscore symbol and file extension are not needed when referencing a partial; they can be omitted. However, if you want to add them, that's fine too. Omitting them keeps the code cleaner.

Many professionals say extend or inherit is one of the most useful features of Sass. Others actually recommend staying away from it. This book's recommendation is: just use Sass as much as possible and experiment with different features so you can create your own opinions. When you have enough experience, you can decide which side you want to join.

Extending in Sass means that we can use a selector's properties in another selector without having to type all those properties again. This is called inheriting. We use the @extend directive for this.

For example, consider the following selector:

$brandBlue: #416e8e; .generic-container {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: #ccc;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

Suppose we want to inherit all the properties of this selector on a different selector. We're also going to modify one property, since they are almost identical, using the @extend directive to reuse the styles of the first selector in the second one:

.box-customer-service {
    @extend .generic-container;
    padding: 25px;
}

This compiles to the following:

.generic-container, .box-customer-service {
    padding: 10px;
    border: #416e8e 1px solid;
    background: #cccccc;
    box-shadow: 1px 1px 1px rgba(0, 0, 0, 0.3);
}

.box-customer-service {
    padding: 25px;
}

Notice that .generic-container and .box-customer-service are in the same rule; this means that .box-customer-service is inheriting all the properties and values of .generic-container. Then, there's a separate rule for .box-customer-service, where only the padding property is declared since it's the only difference between the two containers.

Since we know that a CSS document is a valid SCSS document, using the CSS comment syntax is also valid:

/* This is a traditional CSS comment */

In Sass, there's another way. We can comment using double slashes (//) at the beginning:

// This is a Sass-style comment

The difference between the two styles is that the traditional CSS comment using /**/ syntax gets added to the compiled file, whereas the comments with Sass using // does not get added.

The comments with the Sass syntax are very helpful to document our SCSS files without having to worry about all those comments getting compiled and bloating our final CSS file. The Sass comment in the following example doesn't get compiled:

$brandBlue: #416e8e; //Mixin for generic container across the app
.generic-container {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: #ccc;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

However, the traditional CSS comment does get compiled:

$brandBlue: #416e8e;
/* Mixin for generic container across the app */
.generic-container {
    padding: 10px;
    border: $brandBlue 1px solid;
    background: #ccc;
    box-shadow: 1px 1px 1px rgba(black, .3);
}

Vendor prefixing is basically adding a specific tag to a CSS3 property or value that hasn't been widely used by the web development industry and communities or finalized and included in the CSS3 specification.

The vendor part refers to the abbreviation tags that represent the names of the companies that create the browsers: Mozilla, Opera, and Microsoft.

There's one exception though, Apple. Although Apple created Safari, the vendor prefix is based on the layout engine of the browser rather than the company name.

The prefix part refers to the description of adding the vendor tags before the CSS property or CSS value. Each vendor prefix only works in its own browser, so for the preceding list, here are the browsers they belong to:

If you're wondering where Google Chrome is in all this, there's a simple explanation.

Although Google created Chrome, there is no specific prefix for Chrome. In the beginning, Chrome was using the same layout engine as Safari: Webkit. Thus, the Webkit-based prefixes not only affected Safari, but also affected Chrome and other Chromium-based products.

However, Google Chrome no longer uses Webkit; it now uses its own layout engine called Blink. However, in order to maintain compatibility and avoid fragmenting the Web even more, Chrome still supports the -webkit- prefix.

Opera had a similar story where they had their own layout engine, Presto, and then switched to Webkit. It now uses Blink. There are other browser vendors in addition to the ones mentioned before and they use their own prefixes as well, such as the Konqueror browser with its prefix, -k-.

Here's an example of a vendor-prefixed CSS property:

-moz-box-sizing: border-box;

And, here's an example of a prefixed CSS value:

background-image: -webkit-linear-gradient(red, blue);

*, *:before, *:after {
    background-image: -webkit-linear-gradient(red, blue);
    background-image: -moz-linear-gradient(red, blue);
    background-image: -ms-linear-gradient(red, blue);
    background-image: -o-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

@import "compass/css3/images";

header {
    @include background-image(linear-gradient(red, blue));
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

header {
    background-image: url('data:image/svg+xml;base64,…');
    background-size: 100%;
    background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, red), color-stop(100%, blue));
    background-image: -moz-linear-gradient(red, blue);
    background-image: -webkit-linear-gradient(red, blue);
    background-image: linear-gradient(red, blue);
}

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Page Title</title>
    <link href="css/styles.css" rel="stylesheet">
    <script src="js/prefixfree.min.js"></script>
</head>
<body>
    Site content...
</body>
</html>

npm install --global autoprefixer
autoprefixer *.css

gem install autoprefixer-rails

{
    "in": "style.css",
    "out": "styles.fixed.css"
}

pleeease compile

.selector-a {
    -trf
}

.selector-a {
    -webkit-transform:;
    -ms-transform:;
    -o-transform:;
    transform:;
}

Using the command line to compile our SCSS files is really not that difficult:

--sass watch scss:css

That's all we need to do in the command line to have Sass watch over the SCSS files in the /scss folder and compile them into the /css folder. It really is that simple.

The problem with the previous situation is that we need to run this command every single time we have to work on a different project. Although we can automate this in many different ways, some find the use of the command line either daunting or just unnecessary.

The Prepros app

Prepros is a tool for web designers and developers that deals with many parts of a regular workflow: compiling, CSS prefixing, live refresh, JavaScript concatenation, file minification, optimizing images, browser testing synchronization, source maps creation for compiled files, built-in server, FTP, and so on.

For the scope of this book, we're going to focus on how it can help us compile our SCSS files while adding vendor prefixes automatically.

You can download it from https://prepros.io/. Prepros is a paid application. However, spending $29 is not going to break the bank. I assure you that right after the first compilation, this app will have paid itself.

There is also a way to use Prepros for free and enjoy all the features of the app. However, this comes at the expense of having to keep closing the buy the app pop-up window about every 5 minutes.

This is the current welcome screen of Prepros (it may have changed by now):

Remember the steps in the installation of Sass where we created a /Demo folder and created two subfolders, /scss and /css, within it? We are going to drag and drop the /Demo folder onto the Prepros interface:

A sad face appears, letting us know that the project is empty. This is true since we haven't added any files to the /scss folder:

So, let's create a .scss file in the /scss folder:

Prepros will automatically detect the new styles.scss file and compile it to create the styles.css file, which is saved in the /css folder.

Clicking on the styles.scss file will bring out the file's default settings:

Let's modify some of these settings so Prepros can automatically perform the following operations:

• Add vendor prefixes.
• Create source maps.
• Not compress our compiled CSS (at least yet).

Tip

The source map is a file with the .map extension that gets generated together with our CSS file. This map file contains the necessary information that links each line of our CSS file to their corresponding line in our SCSS files and partials. This is crucial when we need to inspect the styles of an element via the DevTools of any modern web browser.

In the OUTPUT STYLE section, we're going to leave the setting as Expanded.

The differences between the four styles of output are simple:

Expanded output

This is the traditional CSS styling where each selector, property, and value is in a separate line:

header {
    background: blue;
}
header .logo {
    float: left;
}
.container {
    float: right;
}

Nested output

You can see that the second rule is indented, which means it belongs to the header selector:

header {
    background: blue;
}
    header .logo {
       float: left;
  }
.container {
    float: right;
}

Compact output

All rules reside in a single line, as shown here:

header { background: blue; }
header .logo { float: left; }
.container { float: right; }

Compressed output

This is the minified version, which is the version we should use in production:

header{background:blue;}header .logo{float:left;}.container{float:right;}

That's it. We now leave Prepros running. It will add all vendor prefixes and compile the SCSS files every time we save it. Let's see this in action.

Add some CSS and let the Prepros app do the rest!

Every time we hit Save, Prepros will show either one of the following dialog boxes at the bottom-right corner of our screen.

Success will give us the following output:

Error will give us the following output:

Let's take our styles.scss file and let's add a simple CSS rule that requires some vendor prefixing.

When we save the styles.scss file, Prepros shows the green/success dialog box and compiles our SCSS file to styles.css.

This is what the compiled file looks like with all the prefixes added automatically:

Defining how many legacy browser versions to support for prefixing

As browsers evolve, CSS3 properties and values are standardized and less of them require vendor prefixing. Our CSS files should reflect that so we don't fill our style sheets with unnecessary prefixes.

Prepros allows us to define how many legacy browser versions we want to support when applying prefixes. The steps are as follows:

1. Click on the MORE OPTIONS menu at the top:
   
2. Click on Project Options from the drop-down menu:
   
3. Click on the CSS menu option:
   
4. Scroll all the way to the bottom and type the number 2 in the AutoPrefixer field:
   
5. Once this is done, save the styles.scss file. We'll see that the CSS3 linear gradient property doesn't really need to be prefixed after Prepros compiles the CSS file:
   

Tip

If you are not able to see the linear gradient property prefixed in the beginning, try changing the value to something very high, such as 40 so that it reads last 40 versions. Save your SCSS document and check your CSS file again.

That's all there is to it.

There are many ways to create a Sass mixin to house media queries: mixins with variables only, mixins with the No Queries fallback for older browsers that don't support media queries, and plugins (for Compass) such as Breakpoint. There are other techniques too, such as Named Media Queries. Another technique is a simple three-line mixin that will work for anything we want.

They're all fine and very powerful. However, for the scope of this book, we're going to focus on two simple methods that will allow us to be efficient, keep things simple, and harness the power of mixins.

All that you have learned about Sass so far, especially the part about mixins, culminates in the creation of a partial file that will house our media queries for RWD.

Remember that partial files are SCSS files we create to house SCSS snippets. Their file name starts with an underscore symbol and ends with the .scss extension.

//Mobile-first
@mixin minw($point) {
    @if $point == 320 {
      @media (min-width:  20em) { @content; }
    }
    @else if $point == 640 {
      @media (min-width:  40em) { @content; }
    }
    @else if $point == 768 {
      @media (min-width:  47.5em) { @content; }
    }
}

header {
    width: 50%; //Properties for small screens
    background: red;
      @include minw(640) {
          width: 100%; //Properties for large screens
          background: blue;
  }
}

header {
    width: 50%;
    background: red;
}
@media (min-width: 40em) {
    header {
      width: 100%;
      background: blue;
    }
}

//Mobile-first

@mixin minw($point)

@if $point == 320

@media (min-width:  20em)

@media (min-width:  20em) { @content; }

@else if $point == 640

@media (min-width:  40em) { @content; }

//Mobile-first
@mixin breakpoint($point) {
    @if $point == small {
        @media (min-width:  20em) { @content; }
    }
    @else if $point == medium {
        @media (min-width:  40em) { @content; }
    }
    @else if $point == large {
        @media (min-width:  48em) { @content; }
    }
}

header {
    width: 50%; //Properties for small screens
    background: red;
    @include breakpoint(medium) {
        width: 100%; //Properties for large screens
        background: blue;
    }
}

header {
    width: 50%;
    background: red;
}
@media (min-width: 40em) {
    header {
        width: 100%;
        background: blue;
    }
}

@mixin mobileFirst($media) {
    @media (min-width: $media/16+em) { @content; }
}

header {
    width: 50%; //Properties for small screensbackground: red;
    @include mobileFirst(640) {
        width: 100%; //Properties for large screensbackground: blue;
   }
}

header {
    width: 50%;background: red;
}
@media (min-width: 40em) {
    header {
      width: 100%;background: blue;
  }
}

WAI-ARIA landmark roles can also be referred to as ARIA roles, so that's the term we're going to use.

An ARIA role looks like this when implemented in an HTML5 element:

<header role="banner">

There are really multiple ARIA roles at our disposal, but in this book we're going to focus on the ones that are easier to implement and that will enhance the accessibility of our websites/apps efficiently.

<header class="masthead" role="banner">
    <div class="logo">Mastering RWD with HTML5 &amp; CSS3</div>
    <div class="search" role="search">
      <form>
         <label>Search:
            <input type="text" class="field">
            <button>Search Now!</button>
         </label>
      </form>
    </div>
</header>

<nav class="main-nav" role="navigation">
    <ul class="nav-container">
      <li><a href="#">Link 1</a></li>
      <li><a href="#">Link 2</a></li>
      <li><a href="#">Link 3</a></li>
      <li><a href="#">Link 4</a></li>
    </ul>
</nav>

<footer class="main-footer" role="contentinfo">
    <p>Copyright &copy;</p>
    <ul class="nav-container" role="navigation">
      <li><a href="#">Footer Link 1</a></li>
      <li><a href="#">Footer Link 2</a></li>
      <li><a href="#">Footer Link 3</a></li>
      <li><a href="#">Footer Link 4</a></li>
      <li><a href="#">Footer Link 5</a></li>
    </ul>
</footer>

<body>
    <main class="main-container" role="main">Content goes here
    </main>
</body>

<footer class="main-footer" role="contentinfo">
    <p>Copyright &copy;</p>
    <ul class="nav-container" role="navigation">
      <li><a href="#">Footer Link 1</a></li>
      <li><a href="#">Footer Link 2</a></li>
      <li><a href="#">Footer Link 3</a></li>
      <li><a href="#">Footer Link 4</a></li>
      <li><a href="#">Footer Link 5</a></li>
    </ul>
</footer>

<div class="search">
    <form role="search">
      <label>Search:
         <input type="text" class="field">
         <button>Search Now!</button>
      </label>
    </form>
</div>

<div class="contact-form" role="form">
    <header>
      <h2>Have Questions About HTML5?</h2>
    </header>
    <form>
      <div class="flex-container">
         <label class="label-col">Name: <input type="text" class="field name" id="name" required></label>
         <label class="label-col">Email: <input type="email" class="field email" id="email" required></label>
      </div>
      <label for="comments">Comments:</label>
      <textarea class="comments" id="comments" cols="50" required></textarea>
      <button>Send Question!</button>
    </form>
</div>

<aside class="side-content" role="complementary">
    <h2>What Does "Semantic HTML" Mean?</h2>
    <p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>
</aside>

There are many ways web designers and developers use meta tags, but those extensive explanations are outside the scope of this book, so we're going to focus on the bits and pieces that are relevant and work as intended for RWD.


The following meta tags are very important for our responsive site/app. These meta tags are not just for HTML5 pages, they will work with any version of HTML.

Let's get started.

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

<meta name="viewport" content="width=960">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

<meta charset="utf-8">

We're going to use the following mobile-first mixin:

@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content; }
}

This is how we use it:

header {
   //Properties for small screens
    width: 50%;
    background: red;
    @include forLargeScreens(640) {
      //Properties for large screens
        width: 100%;
        background: blue;
    }
}

This compiles to the following:

header {
    width: 50%;
    background: red;
}

@media (min-width: 40em) {
    header {
        width: 100%;
        background: blue;
    }
}

Here's the desktop-first mixin we're going to use:

@mixin forSmallScreens($media) {
    @media (max-width: $media/16+em) { @content; }
}

This is how we use it:

header {
    //Properties for large screens
    width: 100%;
    background: purple;
    @include forSmallScreens(640) {
      //Properties for small screens
        width: 50%;
        background: yellow;
    }
}
@include forSmallScreens

This compiles to the following:

header {
    width: 100%;
    background: purple;
}

@media (max-width: 40em) {
    header {
        width: 50%;
        background: yellow;
    }
}

Respond.js is a type of script called a polyfill. A polyfill, according to the one who coined the term in the first place, Remy Sharp, is a piece of code that provides the technology that we, web developers, expect browsers to provide natively.

In web design and development, polyfills are more abundant as JavaScript implementations, in our case, Scott Jehl's Respond.js. But we could also say that there are polyfills in CSS too, for example, the well-known reset.css from Eric Meyer and Normalize.css from Nicolas Gallagher and Jonathan Neal.

The Respond.js script is a polyfill that makes legacy browsers (IE6/7/8) support a particular CSS feature they were never made to support: media queries.

You can download Respond.js from https://github.com/scottjehl/Respond.

So, here's what you need to do:

Here's our example HTML:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Mastering RWD with HTML5 &amp; CSS3</title>
    <link href="styles.css" rel="stylesheet">
</head>
<body>
    <header>Logo goes here…</header>
    <article>Content goes here…</article>
    <script src="js/respond.min.js"></script>
</body>
</html>

In our styles.scss file, we type the following lines:

//Mobile-first declaration
article { background: red;
    //Target screens 640px wide and larger
    @include forLargeScreens(640) {
        & { background: green; }
  }
}

This compiles to the following:

article {
    background: red;
}

@media (min-width: 40em) {
    article {
         background: green; 
    }
}

So, when you resize an IE7 or IE8 browser window, it will be able to display a red background if the window width is 640 pixels or less, and a green background if the window is 641 pixels or more.

I've avoided creating IE-specific style sheets since I started writing CSS. The reasons for this are simple:

<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->

.ie7 nav li {
    float: left;
}

.ie7, .ie8, .ie9 {
    nav li {
        float: left;
    }
}

.ie7 nav li, .ie8 nav li, .ie9 nav li {
    float: left;
}

nav {
    display: flex;
}

Vectors like SVGs, Icon Fonts, or regular fonts are a visual representation of mathematical equations, thus they never lose quality, no matter their size.

In order for bitmap images to display well on high-density screens, we have to export a high-resolution version of the normal-quality image. This means that we need to create two files (or more) for every bitmap image we plan to use: one normal-quality image for non-high-density screens (standard LCD displays, old TFT monitors, some TVs, and so on) and one (or more) high-quality image for high-density screens (any retina devices and Super AMOLED displays, for example).

This is where good design judgment comes into play, because sometimes we may not necessarily need to export two (or more) bitmap images every time.

There are several techniques that we can use to deal with images when we have to consider high-density screens. These techniques are explained in detail in Chapter 6, Working with Images and Videos in Responsive Web Design.

The graphic you see here is proportional to a 12-column 980GS layout. The browser window is 1024px wide and the page is 980px wide:

The following are the container's components:

Here's the markup that represents our base page:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Retrofitting with Adaptive Web Design</title>
    <link href="css/styles.css" rel="stylesheet">
</head>
<body>
    <main class="container_12 clear">
      <header class="grid_12">Header</header>
      <nav class="grid_3">Nav</nav>
      <section class="grid_9">Content</section>
      <footer class="grid_12">Footer</footer>
    </main>
</body>
</html>

Regarding our CSS/SCSS, we are only going to need to create one partial, the _980gs.scss file that contains the fixed-width grid.

Then, we're going to create a styles.scss file with which we are going to perform the following operations:

//Globals
*, *:before, *:after {
    box-sizing: border-box;
}

//Container
.container_12 {
    width: 980px;
    padding: 0 10px;
    margin: auto; 
}

//Grid >> Global
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
      float: left;
      margin: 0 10px;
    }
}

//Grid >> 12 Columns
.container_12 {
    .grid_1  { width: 60px; }
    .grid_2  { width: 140px; }
    .grid_3  { width: 220px; }
    .grid_4  { width: 300px; }
    .grid_5  { width: 380px; }
    .grid_6  { width: 460px; }
    .grid_7  { width: 540px; }
    .grid_8  { width: 620px; }
    .grid_9  { width: 700px; }
    .grid_10 { width: 780px; }
    .grid_11 { width: 860px; }
    .grid_12 { width: 940px; }
}

//Clear Floated Elements - http://davidwalsh.name/css-clear-fix
.clear, .row {
    &:before,
    &:after { content: ''; display: table; }
    &:after { clear: both; }
}

//Use rows to nest containers
.row { margin-bottom: 10px;
    &:last-of-type { margin-bottom: 0; }
}
//Legacy IE
.clear { zoom: 1; }

The first thing we're going to do in the styles.scss file is to import the partial _980gs.scss file:

//Retrofitting with Adaptive Web Design
@import "980gs";

Then, we're going to include our simple desktop-first mixin to handle the media queries. However, remember I mentioned before how this is mixin is scalable and we could make it compile pixel-based values if we wanted to? All we need to do is remove the value /16+em from the division $media/16+em:

//Retrofitting with Adaptive Web Design
@import "980gs";

//Desktop-first Media Query Mixin
@mixin forSmallScreens($media) {
    @media (max-width: $media) { @content; }
}

The following rules are merely for styling purposes in order to accomplish the same design we saw in the screenshot before:

//Retrofitting with Adaptive Web Design
@import "980gs";

//Desktop-first Media Query Mixin
@mixin forSmallScreens($media) {
    @media (max-width: $media) { @content; }
}

//Basic styling
.container_12 {
    background: #aaa;
    font-size: 30px;
    text-shadow: 0 1px 1px rgba(black,.5);
}
header { background: #429032; }
nav { background: #2963BD; }
section { background: #c90; }
footer { background: #c03; }

//Give heights to elements for better perception of sections
header, footer { height: 150px; }
nav, section { height: 440px; }

At this point, our page is 980px wide and it looks like the screenshot we initially saw.

Let's define the widths at which we are going to make our base page snap to:

This is where the fun begins. Let's start retrofitting this page by creating the media queries for each section.

980px to 768px (AWD)

The following media queries are aimed at 768px:

.container_12 {
  @include forSmallScreens(980px) {
      width: 768px;
  }
    .grid_12 { //Header and Footer sections
      @include forSmallScreens(980px) {
        width: 728px;
    }
  }
  .grid_3 { //Nav section
    @include forSmallScreens(980px) {
      width: 200px;
    }
  }
  .grid_9 { //Content section
    @include forSmallScreens(980px) {
      width: 508px;
    }
  }
}

Admittedly, it is a bit hard to perceive the difference in the book from 980px to 768px, but believe me, the following screenshot fully represents a browser window 980px wide and a page 768px wide:

As you can see, the moment the screen is 980px, the width of our main container (.container_12) goes from 980px to 768px. Our main container has 10px padding to the left and the right, so the widths of all other sections should add up to match 748px.

Let's take a look.

Our Header and Footer that use the same class .grid_12 are now 728px wide. So if we add: 728px + 10px left margin + 10px right margin = 748px.

If we add the widths of our Nav (.grid_3) and Content (.grid_9) sections:

• 200px Nav + 508px Content = 708px
• 708px + 20px gutter = 728px
• 728px + 10px left margin on Nav + 10px right margin on Content = 748px

Stay with me, I promise this will be very interesting.

768px to 640px (AWD)

The following media queries are aimed at 640px:

.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
  }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    .grid_12 { //Header and Footer sections
      @include forSmallScreens(980px) {
        width: 728px;
      }
      @include forSmallScreens(768px) {
        width: 600px;
      }
    }
    .grid_3 { //Nav section
      @include forSmallScreens(980px) {
        width: 200px;
      }
      @include forSmallScreens(768px) {
        width: 160px;
      }
    }
    .grid_9 { //Content section
      @include forSmallScreens(980px) {
        width: 508px;
      }
      @include forSmallScreens(768px) {
        width: 420px;
      }
    }
}

Ok, this layout is now a single column page. We're starting to see some results. Nice!

Again, remember that our main container has 10px padding to the left and the right, thus the widths of all other sections should add up to match 620px.

Let's make sure our numbers add up:

Our Header and Footer that use the same class .grid_12 are now 600px wide. So if we add: 600px + 10px left margin + 10px right margin = 620px.

If we add the widths of our Nav (.grid_3) and Content (.grid_9) sections:

• 160px Nav + 420px Content = 580px
• 580px + 20px gutter = 600px
• 600px + 10px left margin on Nav + 10px right margin on Content = 620px

Let's make this page even smaller!

640px to 480px (AWD)

The following media queries are aimed at 480px:

.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    @include forSmallScreens(640px) {
      width: 480px;
    }
    .grid_12 { //Header and Footer sections
      @include forSmallScreens(980px) {
        width: 728px;
      }
      @include forSmallScreens(768px) {
        width: 600px;
      }
    }
    .grid_3 { //Nav section
      @include forSmallScreens(980px) {
        width: 200px;
      }
      @include forSmallScreens(768px) {
        width: 160px;
      }
    }
    .grid_9 { //Content section
      @include forSmallScreens(980px) {
        width: 508px;
      }
      @include forSmallScreens(768px) {
        width: 420px;
      }
    }
    .grid_3,
    .grid_9,
    .grid_12 {
      @include forSmallScreens(640px) {
        width: 440px;
      }
    }
}

We're making some well-deserved progress! Here, the browser window is 640px wide and the page is 480px wide:

Remember that our main container has 10px padding to the left and the right, thus the widths of all other sections should add up to match 460px.

Now, we are going to change from a 2-column to a 1-column layout. This means that all sections now have the exact same width.

This also means that in our SCSS file, we can create a single media block for all three classes:

.grid_3,
.grid_9,
.grid_12 {
    @include forSmallScreens(640px) {
      width: 440px;
    }
}

Now, let's make sure our numbers add up:

Our Header, Nav, Content, and Footer sections are now 440px wide, stacked one on top of the other. So if we add: 440px of all sections + 10px left margin + 10px right margin = 460px.

Here we go, the last piece of this puzzle!

480px to 320px (AWD)

The following media queries are aimed at 320px:

.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    @include forSmallScreens(640px) {
      width: 480px;
    }
    @include forSmallScreens(480px) {
      width: 320px;
      padding: 0;
    }
    .grid_12 { //Header and Footer sections
      @include forSmallScreens(980px) {
        width: 728px;
      }
      @include forSmallScreens(768px) {
        width: 600px;
      }
    }
    .grid_3 { //Nav section
      @include forSmallScreens(980px) {
        width: 200px;
      }
      @include forSmallScreens(768px) {
        width: 160px;
      }
      @include forSmallScreens(640px) {     
        height: 50px; //This is only for styling
      }
    }
    .grid_9 { //Content section
      @include forSmallScreens(980px) {
        width: 508px;
      }
      @include forSmallScreens(768px) {
        width: 420px;
      }
    }
    .grid_3,.grid_9,.grid_12 {
      @include forSmallScreens(640px) {
        width: 440px;
      }
      @include forSmallScreens(480px) {
        width: 300px;
      }
    }
}

There we go! In this screenshot, the browser window is 320px wide—the content is 320px wide as well and fits very nicely:

We already know that our main container has 10px padding to the left and the right. In this case, we are going to remove that padding to gain those 20 pixels, since our screen real estate is now very small:

@include forSmallScreens(480px) {
    width: 320px;
    padding: 0;
}

The 10px spacing on the left and right are now going to be created by the left and right margins from the other sections. This means that the width of each section should be 300px.

Adding the new 320px breakpoint is easy:

.grid_3,
.grid_9,
.grid_12 {
    @include forSmallScreens(640px) {
      width: 440px;
    }
    @include forSmallScreens(480px) {
       width: 300px;
    }
}

Now, let's make sure our numbers add up:

Our Header, Nav, Content, and Footer sections are now 300px wide, stacked one on top of the other. So if we add: 300px of all sections + 10px left margin + 10px right margin = 320px.

That's it. We have now retrofitted a fixed-width page to be responsive with the AWD technique.

The final SCSS is as follows:

.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    @include forSmallScreens(640px) {
      width: 480px;
    }
    @include forSmallScreens(480px) {
      width: 320px; padding: 0;
    }
    .grid_12 { //Header and Footer sections
      @include forSmallScreens(980px) {
        width: 728px;
      }
      @include forSmallScreens(768px) {
        width: 600px;
      }
    }
    .grid_3 { //Nav section
      @include forSmallScreens(980px) {
        width: 200px;
      }
      @include forSmallScreens(768px) {
        width: 160px;
      }
      @include forSmallScreens(640px) {     
        height: 50px; //This is only for styling
      }
    }
    .grid_9 { //Content section
      @include forSmallScreens(980px) {
        width: 508px;
      }
      @include forSmallScreens(768px) {
        width: 420px;
      }
    }
    .grid_3, .grid_9, .grid_12 {
      @include forSmallScreens(640px) {
        width: 440px;
      }
      @include forSmallScreens(480px) {
        width: 300px;
      }
    }
}

It compiles to the following CSS:

@media (max-width: 980px) {
    .container_12 {
      width: 768px;
    }
}
@media (max-width: 768px) {
    .container_12 {
      width: 640px;
    }
}
@media (max-width: 640px) {
    .container_12 {
      width: 480px;
    }
}
@media (max-width: 480px) {
    .container_12 {
      width: 320px;
      padding: 0;
  }
}
@media (max-width: 980px) {
    .container_12 .grid_12 {
      width: 728px;
    }
}
@media (max-width: 768px) {
    .container_12 .grid_12 {
      width: 600px;
    }
}
@media (max-width: 980px) {
    .container_12 .grid_3 {
      width: 200px;
    }
}
@media (max-width: 768px) {
    .container_12 .grid_3 {
      width: 160px;
    }
}
@media (max-width: 640px) {
    .container_12 .grid_3 {
      height: 50px;
    }
}
@media (max-width: 980px) {
    .container_12 .grid_9 {
      width: 508px;
    }
}
@media (max-width: 768px) {
    .container_12 .grid_9 {
      width: 420px;
    }
}
@media (max-width: 640px) {
    .container_12 .grid_3, .container_12 .grid_9,.container_12 .grid_12 {
      width: 440px;
    }
}
@media (max-width: 480px) {
    .container_12 .grid_3,.container_12 .grid_9,.container_12 .grid_12 {
      width: 300px;
  }
}

Tip

As you can see, several breakpoints are repeated in our final CSS file. This is an issue with Sass. However, it's really not an issue or something we need to worry about because when this file is gzipped by the server, it will compress it at its maximum. If we minimize the final output (which we should anyhow), we'll be compressing the file even more. The repeated @media breakpoints have very little if any impact on performance.

Now, let's see how retrofitting the same page looks when using percentages and RWD.

Discovered/created by Ethan Marcotte, who coined the term Responsive Web Design, the RWD magic formula is a very simple equation:

(target ÷ context) x 100 = result %

Before we start turning pixels into percentages, we need to see which width our context is going to be.

Our context is going to be the main container of the page .container_12, which has a maximum width of 980px. However, there's a catch involving the main container and the columns that will turn this 980px context into 960px. Notice the 10px left-right padding on the .container_12 section and the 10px left-right margin in the .grid rules:

.container_12 {
    width: 980px;
    padding: 0 10px;
    margin: auto; 
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
      float: left;
      margin: 0 10px;
    }
}

The 10px left-right margin in the .grid rule means that the widths of all the columns have an additional 20px. So, for example, the header and footer that are 940px wide are really 960px wide. The box-sizing: border-box; property only accounts for subtracting what's inside the box model (padding), not what's outside (margin).

One solution would be to remove the 10px left-right padding on .container_12 and increase the left-right margin in the .grid rule to 20px in order to keep the gutters; otherwise, the columns would touch.

Now, the gutters become wider and this may not be intended for design purposes, and—believe it or not—somehow an extra 1px is added to the widest containers. In our case, it is added to the header and footer.

As a designer, I know I do not want to deal with any of those issues if I don't have to.

The second solution is simpler: make the context 960px. This way, we can remove the 10 extra pixels globally without affecting the integrity of the main container and the columns, and the resulting values are almost the same since we're getting percentages.

In other words: (960px ÷ 980px) x 100 = 97.95918367346939% (97.95%)

It's practically the same as: (940px ÷ 960px) x 100 = 97.91666666666667% (97.91%)

In the second solution, the 1px issue does happen, but happens at random widths when resizing the browser. However, the 1px issue is permanent with the first solution, regardless of the browser's width.

With this part clear, we are then going to turn all pixel-based widths into percentages using 960px as their context.

Both the Header and Footer sections have the same width, 940px. Knowing that their context is 960px, let's go ahead and find their widths in percentages using the magic formula: (940px ÷ 960px) x 100 = 97.91666666666667%.

You might be asking yourselves, "are that many decimals necessary?" Not all of them, but at least two are recommended.

So we end up with the Header and Footer sections of 97.91 percent.

Some developers recommend using all the decimals and letting the browser decide how many it wants to use. In the past, I decided to challenge this recommendation and use only two decimals to see what happened. Since I started using two decimals, I haven't experienced any unwanted behavior or width issues whatsoever in any browser.

Firefox and IE11 trim the excess decimals to two. Chrome, on the other hand, leaves all the decimals. I recommend using no less than two decimals, which is what we're going to use in the book to keep things simple and short. However, if you prefer to use all the decimals, by all means, go for it! At this point, it is a matter of personal preference.

To find the width of the Nav section in percentages, we use 960px as its context as well: (220px ÷ 960px) x 100 = 22.91666666666667%.

Using two decimals, we end up with a Nav section of 22.91 percent.

To find out the width of the Content section in percentages, our formula looks almost identical. The only difference is that we are changing the first value which corresponds to the width of the Content section in pixels: (700px ÷ 960px) x 100 = 72.91666666666667%.

Using only two decimals, our final value is a Content section of 72.91 percent.

This is what our initial retrofitting RWD SCSS file starts to look like:

.container_12 {
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
}

Now, let's take a step back and address a few other pixel-based widths before we continue. Remember the 10px padding to the left and the right of the main container .container_12? We need to turn those 10px into percentages as well.

With our magic formula, we do it like this:

(10px ÷ 960px) x 100 = 1.041666666666667%.

Using only two decimals, our final value is a left and right padding of 1.04 percent.

Let's add this value to our SCSS:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto; 
}
.container_12 {
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
}

Also, all our columns have a 10px margin to the left and right. Since we already know that 10px is 1.04 percent, let's add this value to all our columns in our SCSS:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto; 
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
      float: left;
      margin: 0 1.04%;
    }
}
.container_12 {

    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
}

Now, we have a browser window 1024px wide, a layout 980px wide, and all the columns at their corresponding percentage values. In reality, this is practically impossible without looking at the code to visually tell the differences between the fixed width and the percentage-based layouts.

We're doing good here!

Let the fun begin. Let's add our first media query.

980px to 768px (RWD)

The following media query is aimed at 768px:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto; 
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
      float: left;
      margin: 0 1.04%;
    }
}
.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
}

Since the widths of the Header, Footer, Nav, and Content sections, their paddings, and their margins are set in percentages now, we don't have to declare any media queries for them—at least not yet because the layout hasn't changed.

When we resize our browser window, the Header, Footer, Nav, and Content sections automatically respond, shrink proportionally, snap properly, and fit the new width of the main container .container_12 without breaking the layout. This is shown in the following screenshot:

This is awesome!

Let's add another breakpoint.

768px to 640px (RWD)

In the following breakpoint (640px), our layout is going to change to a single column. So we are going to add a new media query that will make the Nav and Content sections as wide as the Header and Footer sections, and make them stack on top of each other.

The following media query is aimed at 640px and makes the Nav and Content sections full width:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto;
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
        float: left;
        margin: 0 1.04%;
    }
}
.container_12 {
    @include forSmallScreens(980px) {
        width: 768px;
    }
    @include forSmallScreens(768px) {
        width: 640px;
    }
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
      width: 72.91%;
    }
    .grid_3, .grid_9 { //Nav and Content sections
        @include forSmallScreens(640px) {
            width: 97.91%;
        }
    }
}

Ok, we now have a single-column layout. Not bad, not bad!

640px to 480px (RWD)

We are now going as small as 480px and the one-column layout won't change, only the widths of all the containers will change.

The following media query is aimed at 480px:

.container_12 {
  width: 980px;
  padding: 0 1.04%;
  margin: auto; 
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
      float: left;
      margin: 0 1.04%;
    }
}
.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    @include forSmallScreens(640px) {
      width: 480px;
    }
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
      @include forSmallScreens(640px) {     
        height: 50px; //This is only for styling
      }
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
    .grid_3, .grid_9 { //Nav and Content sections
      @include forSmallScreens(640px) {
        width: 97.91%;
      }
    }
}

Our layout is getting narrower and all we needed to do was add a new media query and that was it! No need to mess around with the other containers; they all adapt perfectly to any width we define.

480px to 320px (RWD)

Finally, we address the 320px width without modifying the one-column layout. We remove the padding on .container_12 to make use of all the available screen real estate.

The following media query is aimed at 320px:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto;
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
    float: left;
    margin: 0 1.04%;  }
}
.container_12 {
    @include forSmallScreens(980px) {
      width: 768px;
    }
    @include forSmallScreens(768px) {
      width: 640px;
    }
    @include forSmallScreens(640px) {
      width: 480px;
    }
    @include forSmallScreens(480px) {
      width: 320px; padding: 0;
    }
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
      @include forSmallScreens(640px) {     
        height: 50px; //This is only for styling
      }
    }
    .grid_9 { //Content section
       width: 72.91%;
    }
    .grid_3, .grid_9 {
      @include forSmallScreens(640px) {
        width: 97.91%;
      }
    }
}

Once more, we do not have to add anything to the Header, Footer, Nav, and Content sections, since all of them are now 97.91 percent wide. This makes them responsive and we don't have to worry about anything else.

The final SCSS, combining all breakpoints and widths, is as follows:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto;
}
.grid {
    &_1, &_2, &_3, &_4, &_5, &_6, &_7, &_8, &_9, &_10, &_11, &_12 {
        float: left;
        margin: 0 1.04%;
    }
}
.container_12 {
    @include forSmallScreens(980px) {
        width: 768px;
    }
    @include forSmallScreens(768px) {
        width: 640px;
    }
    @include forSmallScreens(640px) {
        width: 480px;
    }
    @include forSmallScreens(480px) {
        width: 320px; padding: 0;
    }
    .grid_12 { //Header and Footer sections
      width: 97.91%;
    }
    .grid_3 { //Nav section
      width: 22.91%;
    }
    .grid_9 { //Content section
      width: 72.91%;
    }
    .grid_3, .grid_9 { //Nav and Content sections
        @include forSmallScreens(640px) {
            width: 97.91%;
        }
    }
}

It compiles to the following CSS:

.container_12 {
    width: 980px;
    padding: 0 1.04%;
    margin: auto;
}

.grid_1, .grid_2, .grid_3, .grid_4, .grid_5, .grid_6, .grid_7, .grid_8, .grid_9, .grid_10, .grid_11, .grid_12 {
    float: left;
    margin: 0 1.04%;
}

@media (max-width: 980px) {
    .container_12 {
      width: 768px;
    }
}
@media (max-width: 768px) {
    .container_12 {
      width: 640px;
    }
}
@media (max-width: 640px) {
    .container_12 {
      width: 480px;
    }
}
@media (max-width: 480px) {
    .container_12 {
      width: 320px;
      padding: 0;
    }
}
.container_12 .grid_12 {
    width: 97.91%;
}
.container_12 .grid_3 {
    width: 22.91%;
}
.container_12 .grid_9 {
    width: 72.91%;
}
@media (max-width: 640px) {
    .container_12 .grid_3, .container_12 .grid_9 {
      width: 97.91%;
    }
}

As you can see, it's a lot less code using RWD than AWD to retrofit a site. Granted, these examples are an extreme simplification of a site/app layout, but now you are aware of the basic concepts of each technique when the time to make the call of using AWD or RWD knocks on your door.

The idea behind listing pros and cons of CSS grids for RWD is that we should be able to make the most informed decision when we plan to use a certain type of grid. It helps clarify the clients' expectations and ours, because using a certain grid will impact the timeline, design, layout, and many UX factors.

The advantages are as follows:

The disadvantages are as follows:

We're going to use the RWD magic formula: (target ÷ context) x 100 = result %.

Our context is going to be 1200px. So let's convert one column: 80 ÷ 1200 x 100 = 6.67%.

For two columns, we have to account for the gutter that is 20px. In other words, we can't say that two columns are exactly 160px. That's not entirely correct.

Two columns are: 80px + 20px + 80px = 180px.

Let's now convert two columns: 180 ÷ 1200 x 100 = 15%.

For three columns, we now have to account for two gutters: 80px + 20px + 80px + 20px + 80px = 280px.

Let's now convert three columns: 280 ÷ 1200 x 100 = 23.33%.

Can you see the pattern now? Every time we add a column, all that we need to do is add 100 to the value. This value accounts for the gutters too!

Check the screenshot of the grid we saw moments ago, you can see the values of the columns increment by 100.

So, all the equations are as follows:

1   column:    80 ÷ 1200 x 100 = 6.67%
2   columns:  180 ÷ 1200 x 100 = 15%
3   columns:  280 ÷ 1200 x 100 = 23.33%
4   columns:  380 ÷ 1200 x 100 = 31.67%
5   columns:  480 ÷ 1200 x 100 = 40%
6   columns:  580 ÷ 1200 x 100 = 48.33%
7   columns:  680 ÷ 1200 x 100 = 56.67%
8   columns:  780 ÷ 1200 x 100 = 65%
9   columns:  880 ÷ 1200 x 100 = 73.33%
10  columns:  980 ÷ 1200 x 100 = 81.67%
11  columns: 1080 ÷ 1200 x 100 = 90%
12  columns: 1180 ÷ 1200 x 100 = 98.33%

Let's create the SCSS for the 12-column grid:

//Grid 12 Columns
.grid {
    &-1  { width:6.67%; }
    &-2  { width:15%; }
    &-3  { width:23.33%; }
    &-4  { width:31.67%; }
    &-5  { width:40%; }
    &-6  { width:48.33%; }
    &-7  { width:56.67%; }
    &-8  { width:65%; }
    &-9  { width:73.33%; }
    &-10 { width:81.67%; }
    &-11 { width:90%; }
    &-12 { width:98.33%; }
}

Don't forget to include the UTF-8 encoding directive at the top of the file to let browsers know the character set we're using. Let's spruce up our code by adding a Credits section at the top. The code is as follows:

@charset "UTF-8";

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Float-based
    Created by: Your Name
    Date: MM/DD/YY
*/

//Grid 12 Columns
.grid {
    &-1  { width:6.67%; }
    &-2  { width:15%; }
    &-3  { width:23.33%; }
    &-4  { width:31.67%; }
    &-5  { width:40%; }
    &-6  { width:48.33%; }
    &-7  { width:56.67%; }
    &-8  { width:65%; }
    &-9  { width:73.33%; }
    &-10 { width:81.67%; }
    &-11 { width:90%; }
    &-12 { width:98.33%; }
}

Including the box-sizing property allows the browser's box model to account for the padding inside the containers; this means the padding gets subtracted rather than added, thus maintaining the defined width(s).

Since the structure of our custom CSS grid is going to be mobile-first, we need to include the mixin that will handle this aspect:

@charset "UTF-8";

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Float-based
    Created by: Your Name
    Date: MM/DD/YY
*/

*, *:before, *:after {
    box-sizing: border-box;
}

//Moble-first Media Queries Mixin
@mixin forLargeScreens($width) {
    @media (min-width: $width/16+em) { @content }
}

//Grid 12 Columns
.grid {
    &-1  { width:6.67%; }
    &-2  { width:15%; }
    &-3  { width:23.33%; }
    &-4  { width:31.67%; }
    &-5  { width:40%; }
    &-6  { width:48.33%; }
    &-7  { width:56.67%; }
    &-8  { width:65%; }
    &-9  { width:73.33%; }
    &-10 { width:81.67%; }
    &-11 { width:90%; }
    &-12 { width:98.33%; }
}

Since we're using the mobile-first approach, our main container is going to be 100% wide by default; but we're also going to give it a maximum width of 1200px since the requirement is to create a grid of that size.

We're also going to convert 10px into a percentage value, so using the RWD magic formula: 10 ÷ 1200 x 100 = 0.83%.

However, as we've seen before, 10px, or in this case 0.83%, is not enough padding and makes the content appear too close to the edge of the main container. So we're going to increase the padding to 20px: 20 ÷ 1200 x 100 = 1.67%.

We're also going to horizontally center the main container with margin: auto;.

Let's include these values now:

@charset "UTF-8";

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Float-based
    Created by: Your Name
    Date: MM/DD/YY
*/

*, *:before, *:after {
    box-sizing: border-box;
}

//Moble-first Media Queries Mixin
@mixin forLargeScreens($width) {
    @media (min-width: $width/16+em) { @content }
}

//Main Container
.container-12 {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else.
    max-width: 1200px;
    padding: 0 1.67%;
    margin: auto;
}

//Grid 12 Columns
.grid {
    &-1  { width:6.67%; }
    &-2  { width:15%; }
    &-3  { width:23.33%; }
    &-4  { width:31.67%; }
    &-5  { width:40%; }
    &-6  { width:48.33%; }
    &-7  { width:56.67%; }
    &-8  { width:65%; }
    &-9  { width:73.33%; }
    &-10 { width:81.67%; }
    &-11 { width:90%; }
    &-12 { width:98.33%; }
}

On small screens, all the columns are going to be 100% wide. Since we're working with a single column layout, we don't use gutters; this means we don't have to declare margins, at least yet.

At 640px, the grid will kick in and assign corresponding percentages to each column, so we're going to include the columns in a 40em (640px) media query and float them to the left. At this point, we need gutters. Thus, we declare the margin with .83% to the left and right padding.

The code is as follows:

@charset "UTF-8";

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Float-based
    Created by: Your Name
    Date: MM/DD/YY
*/

*, *:before, *:after {
    box-sizing: border-box;
}

//Moble-first Media Queries Mixin
@mixin forLargeScreens($width) {
    @media (min-width: $width/16+em) { @content }
}

//Main Container
.container-12 {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else.
    max-width: 1200px;
    padding: 0 1.67%;
    margin: auto;
}

//Grid
.grid {
    //Global Properties - Mobile-first
    &-1, &-2, &-3, &-4, &-5, &-6, &-7, &-8, &-9, &-10, &-11, &-12 {
        width: 100%;
    }
    @include forLargeScreens(640) { //Totally arbitrary width, it's only a starting point.
    //Global Properties - Large screens
    &-1, &-2, &-3, &-4, &-5, &-6, &-7, &-8, &-9, &-10, &-11, &-12 {
        float: left;
        margin: 0 .83%;
    }
    //Grid 12 Columns
    .grid {
        &-1  { width:6.67%; }
        &-2  { width:15%; }
        &-3  { width:23.33%; }
        &-4  { width:31.67%; }
        &-5  { width:40%; }
        &-6  { width:48.33%; }
        &-7  { width:56.67%; }
        &-8  { width:65%; }
        &-9  { width:73.33%; }
        &-10 { width:81.67%; }
        &-11 { width:90%; }
        &-12 { width:98.33%; }
    }
}

If we use rows in our HTML structure or add the class .clear to a tag, we can declare all the float clearing values in a single nested rule with the :before and :after pseudo-elements.

The float clearing technique is an adaptation of David Walsh's CSS snippet (http://davidwalsh.name/css-clear-fix).

We're also adding a rule for the rows with a bottom margin of 10px to separate them from each other, while removing that margin from the last row to avoid creating unwanted extra spacing at the bottom. Finally, we add the clearing rule for legacy IEs.

Let's include these rules now:

@charset "UTF-8";

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Float-based
    Created by: Your Name
    Date: MM/DD/YY
*/

*, *:before, *:after {
    box-sizing: border-box;
}

//Moble-first Media Queries Mixin
@mixin forLargeScreens($width) {
    @media (min-width: $width/16+em) { @content }
}

//Main Container
.container-12 {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else.
    max-width: 1200px;
    padding: 0 1.67%;
    margin: auto;
}

//Grid
.grid {
    //Global Properties - Mobile-first
    &-1, &-2, &-3, &-4, &-5, &-6, &-7, &-8, &-9, &-10, &-11, &-12 {
        width: 100%;
    }
    @include forLargeScreens(640) { //Totally arbitrary width, it's only a starting point.
    //Global Properties - Large screens
    &-1, &-2, &-3, &-4, &-5, &-6, &-7, &-8, &-9, &-10, &-11, &-12 {
        float: left;
        margin: 0 .83%;
    }
    //Grid 12 Columns
    .grid {
        &-1  { width:6.67%; }
        &-2  { width:15%; }
        &-3  { width:23.33%; }
        &-4  { width:31.67%; }
        &-5  { width:40%; }
        &-6  { width:48.33%; }
        &-7  { width:56.67%; }
        &-8  { width:65%; }
        &-9  { width:73.33%; }
        &-10 { width:81.67%; }
        &-11 { width:90%; }
        &-12 { width:98.33%; }
    }
}

//Clear Floated Elements - http://davidwalsh.name/css-clear-fix
.clear, .row {
    &:before,
    &:after { content: ''; display: table; }
    &:after { clear: both; }
}

//Use rows to nest containers
.row { margin-bottom: 10px;
    &:last-of-type { margin-bottom: 0; }
}

//Legacy IE
.clear { zoom: 1; }

Let's recap our CSS grid requirements:

Notice that there are several nested containers inside their own row (black background). The idea here is to highlight the nested content sections that add up to 12 columns.

Nesting columns are a major advantage of any grid system. In this book, we are harnessing this power so we don't limit the design in any way.

On small screens (320px wide), this is what the container looks like:

On large screens starting at 40em (640px) wide, this is what the layout looks like:

You can see the demo I created on CodePen at http://codepen.io/ricardozea/pen/d6ab6e0293be9b6bac2e16ad37942ed5.

In the following example, we are going to build the same layout we built using the custom CSS grid but using the Flexbox property. This will help us better understand the power of Flexbox and eventually detach us from using CSS grids altogether, while keeping a more semantic structure in our HTML.

A few things to note about the sample page:

This is what the Flexbox layout looks like on small screens (320px wide):

This is what it looks like on large screens. This screen is 768px wide but the content is 40em (640px):

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Basic Layout Using Flexbox</title>
    <!--[if lt IE 9]>
      <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js">
	  </script>
    <![endif]-->
	<!--[if !IE]><!-->
      <script>
        if (/*@cc_on!@*/false && document.documentMode === 10) {
          document.documentElement.className+=' ie10';
        }
      </script>
    <!--<![endif]-->
</head>
<body>
    <h1>Basic Layout Using Flexbox</h1>
    <main class="main-container" role="main">
        <header role="banner">Header</header>
        <!-- Flexible elements need to be wrapped in a container -->
        <div class="flex-container">
            <nav role="navigation">Nav</nav>
            <section>
                <div class="flex-container row-1">
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                </div>
                <div class="flex-container row-2">
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                </div>
                <div class="flex-container row-3">
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                    <div class="level-1">content</div>
                </div>
                <div class="flex-container row-4">
                    <div class="level-1 content-a">content</div>
                    <div class="level-1 content-b">">content</div>
                    <div class="level-1 content-c">content</div>
                </div>
                <p>Content</p>
            </section>
        </div>
        <footer role="contentinfo">Footer</footer>
    </main>
</body>
</html>

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
  box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
//Main container
.main-container {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
//Main container
.main-container {
    width: 100%;
  //Change this value to ANYTHING you want, no need to edit anything else
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
//Main container
.main-container {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
//Main container
.main-container {
    width: 100%;
    //Change this value to ANYTHING you want, no need to edit anything else
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}
//Nav
nav {
    width: 100%;
    @include forLargeScreens(640) {
        width: 33%;
        margin-right: 1.67%;
    }
}
//Content area
section {
    width: 100%;
    @include forLargeScreens(640) {
        width: 65.33%;
    }
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
.main-container {
    //Change this value to ANYTHING you want, no need to edit anything else.
    width: 100%;
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}
//Nav
nav {
    width: 100%;
    @include forLargeScreens(640) {
        width: 33%;
        margin-right: 1.67%;
    }
}
//Content area
section {
    width: 100%;
    @include forLargeScreens(640) {
        width: 65.33%;
    }
}
//Different width containers
.content- {
    @include forLargeScreens(640) {
        &a { width: 30%; }
        &c { width: 42%; }
    }
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
.main-container {
    //Change this value to ANYTHING you want, no need to edit anything else.
    width: 100%;
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}
//Nav
nav {
    width: 100%;
    @include forLargeScreens(640) {
        width: 33%;
        margin-right: 1.67%;
    }
}
//Content area
section {
    width: 100%;
    @include forLargeScreens(640) {
        width: 65.33%;
    }

}
//Different width containers
.content- {
    @include forLargeScreens(640) {
        &a { width: 30%; }
        &c { width: 42%; }
    }
}
//All IEs
.ie8, .ie9, .ie10 {
    //Exact values (desired width − 0.83% = result %) are commented, but they need tweaked to have one value for all IEs
    section {
        .row-1 .level-1 { width: 49.17%; }
        //Exact value is 32.17%
        .row-2 .level-1 { width: 32.20%; }
        //Exact value is 24.17%
        .row-3 .level-1 { width: 23.75%; }
        .row-4 {
          .content-a { width: 19.17%; }
          .content-b { width: 49.17%; }
          //Exact value is 29.17%
          .content-c { width: 28.3%; }
        }
    }
}

/*
    Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
.main-container {
    //Change this value to ANYTHING you want, no need to edit anything else.
    width: 100%;
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
    @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}
//Nav
nav {
    width: 100%;
    @include forLargeScreens(640) {
        width: 33%;
        margin-right: 1.67%;
    }
}
//Content area
section {
    width: 100%;
    @include forLargeScreens(640) {
        width: 65.33%;
    }
}
//Different width containers
.content- {
    @include forLargeScreens(640) {
        &a { width: 30%; }
        &c { width: 42%; }
    }
}
//All IEs
.ie8, .ie9, .ie10 {
    //Exact values (desired width − 0.83% = result %) are commented, but they need tweaked to have one value for all IEs
    section {
        .row-1 .level-1 { width: 49.17%; }
        //Exact value is 32.17%
        .row-2 .level-1 { width: 32.20%; }
        //Exact value is 24.17%
        .row-3 .level-1 { width: 23.75%; }
        .row-4 {
          .content-a { width: 19.17%; }
          .content-b { width: 49.17%; }
          //Exact value is 29.17%
          .content-c { width: 28.3%; }
        }
    }
}
//IE8/9
.ie8, .ie9 {
    .flex-container { overflow: hidden; }
    nav, section { float: left; min-height: 440px; }
    nav { width: 29%; margin-right: 1%; }
    section { width: 70%; }
    footer { clear: both; zoom: 1; }
}

/*
  Custom Fluid & Responsive Grid System
    Structure: Mobile-first (min-width)
    Syntax: SCSS
    Grid: Flexbox-based
    Created by: Your Name
    Date: MM/DD/YY
*/
*, *:before, *:after {
    box-sizing: border-box;
}
//Moble-first Media Queries Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content }
}
.main-container {
    //Change this value to ANYTHING you want, no need to edit anything else.
    width: 100%;
    max-width: 1200px;
    //Any value you want
    padding: 0 1.67%;
    margin: auto;
}
//Flexbox container
.flex-container {
    margin-bottom: 10px;
    //Remove the margin from the last flexbox container
    &:last-of-type {
        margin-bottom: 0;
    }
  @include forLargeScreens(640) {
        display: flex;
    }
}
//DIVs inside the flex container
[class*="level-"] {
    width: 100%;
    @include forLargeScreens(640) {
        margin: 0 .83%;
    }
    &:first-of-type { margin-left: 0; }
    &:last-of-type { margin-right: 0; }
}
//Nav
nav {
    width: 100%;
    @include forLargeScreens(640) {
        width: 33%;
        margin-right: 1.67%;
    }
}
//Content area
section {
    width: 100%;
    @include forLargeScreens(640) {
        width: 65.33%;
    }
}
//Different width containers
.content- {
    @include forLargeScreens(640) {
        &a { width: 30%; }
        &c { width: 42%; }
    }
}
//All IEs
.ie8, .ie9, .ie10 {
    //Exact values (desired width − 0.83% = result %) are commented, but they need tweaked to have one value for all IEs
    section {
        .row-1 .level-1 { width: 49.17%; }
        //Exact value is 32.17%
        .row-2 .level-1 { width: 32.20%; }
        //Exact value is 24.17%
        .row-3 .level-1 { width: 23.75%; }
        .row-4 {
          .content-a { width: 19.17%; }
          .content-b { width: 49.17%; }
          //Exact value is 29.17%
          .content-c { width: 28.3%; }
        }
    }
}
//IE8/9
.ie8, .ie9 {
    .flex-container { overflow: hidden; }
    nav, section { float: left; min-height: 440px; }
    nav { width: 29%; margin-right: 1%; }
    section { width: 70%; }
    footer { clear: both; zoom: 1; }
}
//IE8
.ie8 {
    [class*="level-"] {
        display: inline-block;
        margin: 0 .2%;
    }
}
//IE9
.ie9 {
    [class*="level-"] { float: left; }
}

In his article, Luke talks about the patterns of posture most users have when holding their smartphones, tablets, and touch-enabled laptops:

These patterns allow us to define the best way to lay out our content in order to be easily usable and accessible.

Understanding the posture patterns of our users will allow us to understand when our targets can be the right size or even a bit smaller if there isn't enough screen real estate, or a bit larger if precision is needed, since it's different when someone uses their thumbs as opposed to their index fingers.

Luke also talks about touch zones, which are basically the areas of a device that are either easy or hard to reach, depending on the posture.

In all major styles of devices, smartphones, tablets and touch-enabled laptops, the ideal touch zones are in dark green, the ok touch zones are in lighter green, and the hard-to-reach zones are in yellow:

In RWD, it's a bit hard to drastically change the layout of a single page, let alone many pages (at least yet) like a standalone app, without an exorbitant amount of work. Also, there is a very high probability of negatively impacting the user experience and maintaining the content hierarchy.

RWD is strongly coupled with content strategy, so the content hierarchy needs to be preserved regardless of the device our site/app is being viewed on. We need to make sure the elements themselves are big enough for someone with large fingers to use properly. These elements are, to name a few, links, buttons, form fields, navigation items, controls of any sort like paginations, open/collapse controls in accordions, tab systems, and so on.

Now, there is one website/app element that is quite versatile in RWD: the menu button.

In order to trigger the navigation, there is a very particular element that the UX communities have very strong opinions about: The hamburger icon (≡). For now, we're going to call it something more generic: the nav icon. I'm calling it the nav icon because it doesn't necessarily have to be a hamburger icon/graphic, it can be another type of icon or a word.

The location, behavior, and design of the navigation icon and the navigation items themselves have as many variations as there are designers. What works for others may not necessarily work for us, and vice versa. So, testing becomes the go-to methodology to decide what our users feel comfortable with.

Nonetheless, there are a few UX guidelines for the nav icon that are worth mentioning and that we're going to see next.

This is by far the most popular icon used to represent the navigation button: ≡.

The hamburger icon was created by Norm Cox in 1981. Norm's intention with this icon was to "…mimic the look of the resulting displayed menu list." (http://gizmodo.com/who-designed-the-iconic-hamburger-icon-1555438787).

In other words, the hamburger icon's real name is the list icon.

Now, if we think about it, the hamburger icon is semantically correct because it represents exactly what is displayed when it's triggered: a list of items. However, some UX studies have revealed that the hamburger icon isn't as effective as we may think, and yet we see it all over the place in both responsive sites and mobile apps.

Although the hamburger icon has several cons, it's a matter of time before practically everyone is able to recognize this icon as a representation of navigation.

The bottom line is that there's nothing wrong with using the hamburger icon as long as we follow the target size recommendations and make the links inside the navigation bar easy to tap on small screens.

The advantages are as follows:

The disadvantages are as follows:

If you plan to use the hamburger icon, don't bother using images of any kind or any CSS techniques with borders or box shadows. Keep it simple. All you need to do is use the Unicode character 2261 (≡).

In the following examples, we are going to use a well-known technique to hide content (with a few variations to fit our demos): the Kellum Method. This method is not in any way a hack or anything similar; we are not trying to deceive our users or the search engines with this approach. We're actually being quite mindful of the improved accessibility the navigation icons gain by leaving the text in the markup so that users with assistive technologies can still access the menus. Consider the following example.

The HTML is as follows:

<button class="hamburger-icon"><span>Menu</span></button>SCSS
//Hamburger Icon
.hamburger-icon  {
    //Basic styling, modify if you want
    font-size: 40px;
    color: #666;
    background: #efefef;
    padding: 0 10px;
    border-radius: 3px;
    cursor: pointer;
    //Hamburger Icon
    &:before {
        content: '≡';
    }
    //Hide the term Menu from displaying without sacrificing accessibility
    span {
        display: inline-block;
        width: 0;
        height: 0;
        text-indent: -100%;
        overflow: hidden;
        white-space: nowrap;

    }
}

The result is this one:

Some informal tests on the web have yielded that using the word Menu is the most trusted solution to the drawbacks of the hamburger icon.

However, it's important to note that the studies and tests done by many authors where they compare the hamburger icon versus the word Menu can be misleading, since they are testing different visual languages: an icon versus a word.

For these tests to be fully reliable, they would have to test icon versus icon, and word versus word. For example, testing the hamburger icon against an arrow pointing down or the word Menu against the word Nav.

Let's look at the pros and cons of the word Menu.

The advantages are as follows:

The disadvantage is as follows:

Consider the following example.

Here's the HTML:

<button class="word-menu">Menu</button>

And here's the CSS:

//Word "Menu"
.word-menu {
    //Basic styling, modify if you want
    display: inline-block;
    padding: 16px 8px;
    color: #666;
    font: 12px Arial, "Helvetica Neue", Helvetica, sans-serif;
    background: #efefef;
    border-radius: 3px;
    cursor: pointer;
}

And this is the result:

One alternative to the hamburger icon versus the word Menu discussion is to use both at the same time. Some argue that we may get the best of both worlds by doing this.

The advantages are:

The disadvantage is:

Let's look at two styles that we can use to represent this pattern.

Consider the following example.

The HTML is as follows:

<button class="hamburger-icon-plus-menu style-1">Menu</button>

The SCSS is as follows:

//Hamburger Icon Plus Word "Menu" – Style 1
.hamburger-icon-plus-menu {
    //Basic styling, modify if you want
    display: inline-block;
    font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;
    background: #efefef;
    color: #666;
    border-radius: 3px;
    cursor: pointer;
}
.style-1 {
    padding: 16px 8px;
    font-size: 16px;
    //Hamburger Icon
    &:before {
        content: '≡ ';
    }
}

The result is as follows:

Consider the following example.

The HTML is:

<button class="hamburger-icon-plus-menu style-2">Menu</button>

The SCSS is:

//Hamburger Icon plus Word "Menu" – Style 2
.hamburger-icon-plus-menu {
    //Basic styling, modify if you want
    display: inline-block;

    font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;
    background: #efefef;
    color: #666;
    border-radius: 3px;cursor: pointer;
}
.style-2 {
    padding: 4px 12px 6px;
    font-size: 10px;
    line-height: .8;
    text-align: center;
    //Hamburger Icon
    &:before {
        display: block;
        content: '≡';
        font-size: 40px;
    }
}

And here's the result:

You can see a demo I created in CodePen at http://codepen.io/ricardozea/pen/f4ddc6443bc060004b58a7301aae83db.

On small screens, all navigation patterns use the hamburger icon as a trigger except the Flexbox-based navigation. On large screens, the navigation bar on all examples is a horizontal group of links with centered links.

To improve usability in both the Toggle and the Off-Canvas navigations, the hamburger icon gets the class .active added/removed to offer a visual cue showing that the item has been tapped. This is done with a bit of jQuery.

Including jQuery is part of these demos, so it's necessary to call it for them to work.

The markup shown is only for the menu itself, elements and directives such as the <html> tag and HTML5 Doctype have been purposely left out.

The examples work in all major browsers that have support for relatively advanced CSS3 properties. They don't use the FastClick script to remove the 300 ms delay that mobile devices have by default.

Vendor prefixes have been left out; after all, we should be using Autoprefixer to handle this for us.

Since there's no need to reinvent the wheel, the following examples are based on other authors' demos, such as the ones by Brad Frost and Austin Wulf.

However, all original demos have been forked and extensively scaled, enhanced, cleaned up, optimized, restyled, and ported to Sass in order to fit the scope and style of this book. In other words, the markup and code you'll see has been heavily customized exclusively for you.

Let's begin.

This is by far the most commonly used pattern for navigation both in RWD and mobile apps. It uses the hamburger icon as the trigger for the menu when tapped/clicked. When this happens, the main container slides to the right to reveal the menu on the left and slides back again to the left to hide it.

This example does not depend on JavaScript to work. However, it uses a few unsemantic elements to make it work: the <input> and <label> elements. In defense of this method, it uses the :checked pseudo-class, which has perfect support across the board.

Here's our HTML:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
</head>
<body>
    <!-- Checkbox whose checked/unchecked states trigger the navigation -->
    <input type="checkbox" id="nav-trigger" class="nav-trigger">
    <!-- Hamburger icon -->
    <label for="nav-trigger" class="label-trigger"><span>Menu</span></label>
    <!-- Navigation -->
    <nav role="navigation">
        <ul class="menu">
            <li><a href="#">Link 1</a></li>
            <li><a href="#">Link 2</a></li>
            <li><a href="#">Link 3</a></li>
            <li><a href="#">Link 4</a></li>
            <li><a href="#">Link 5</a></li>
        </ul>
    </nav>
    <!-- Main container -->
    <main class="main-container" role="main">
        <h1>The "Off-Canvas" or "Off-Screen" Navigation</h1>
        <p>On <strong>small screens</strong>, the menu is triggered with a hamburger icon. The menu slides left/right.</p>
        <p>On <strong>large screens</strong> starting at 40em (640px), the menu is a horizontal nav.</p>
    </main>
</body>
</html>

And here's our SCSS:

*, *:before, *:after { box-sizing: border-box; }
//Globals
html, body {
    height: 100%;
    width: 100%;
    margin: 0;
}
//Mobile-first Media Query Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content; }
}
//Mixin for animating the hamburger icon
@mixin animation-nav-icon ( $direction: left, $duration: .2s) {
    transition: $direction $duration;
}
//Menu itself
.menu {
    width: 100%;
    height: 100%;
    margin: 0;
    padding: 0;
    position: fixed;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    z-index: 0;
    list-style: none;
    @include forLargeScreens(640) {
        max-width: 980px;
        min-height: 50%;
        margin: 10px auto 0;
        position: relative;
        text-align: center;
        border: #999 1px dotted;
    }
    //List items
    li {
        width: 100%;
        border-bottom: 1px dotted #999;
        @include forLargeScreens(640) {
            display: inline;
            border: none;
        }
        //Links themselves
        a {
            display: block;
            padding: 1em;
            color: #2963BD;
            text-decoration: none;
            @include forLargeScreens(640) {
                display: inline-block;
            }
        }
    }
}
//Main Container
.main-container {
    max-width: 980px;
    min-height: 100%;
    margin: auto;
    padding: 20px 0 20px 80px;
    position: relative;
    top: 0;
    bottom: 100%;
    left: 0;
    z-index: 1;
    background: #eee;
    @include forLargeScreens(640) {
       padding: 20px;
    }
}
//Navigation Trigger - Hide the checkbox
.nav-trigger {
    position: absolute;
    clip: rect(0, 0, 0, 0);
}
//Label that triggers the checkbox
.label-trigger {
    position: fixed;
    left: 10px;
    top: 10px;
    z-index: 2;
    height: 50px;
    width: 50px;
    cursor: pointer;
    background: #fff;
    border-radius: 2px;
    border: 1px solid #ccc;
    //Hamburger icon
    &:before {
        display: block;
        padding-top: 25px;
        text-align: center;
        content: '≡';
        font-size: 3em;
        line-height: 0;
    }
    //Active hamburger icon
    &.active {
        background: #333;
        color: #fff;
    }
    //Hide the term 'Menu' from displaying without sacrificing accessibility
    span {
        display: inline-block;
        text-indent: -100%;
        overflow: hidden;
        white-space: nowrap;
    }
}
//Animate the menu
.nav-trigger {
    & + label {
        @include animation-nav-icon;
        //Hide the checkbox and label in large screens
        @include forLargeScreens(640) {
            display: none;
        }
    }
    //Animate the label when checkbox is checked
    &:checked + label {
        left: 215px;
    }
    //Animate the main container when checkbox is checked
    &:checked ~ .main-container {
        left: 200px;
        box-shadow: 0 0 5px 1px rgba(black, .15);
    }
}
//Animate the main container
.main-container {
    @include animation-nav-icon;
}
//Avoid horizontal scrollbars due to repositioning of elements
body, html { overflow-x: hidden; }
//Styling stuff not needed for demo
html, body { font-family: Arial, "Helvetica Neue", Helvetica, sans-serif; }
h1, p { margin: 0 auto 1em; }
p { line-height: 1.5; }

Here's the jQuery script:

$(function() {
    //Set up the click behavior
    $(".label-trigger").click(function() {
        //Toggle the class .active on the hamburger icon
        $(this).toggleClass("active");
    });
});

Let's take a look at the screenshots.

Here is what it looks like on small screens in the collapsed state:

Here is what it looks like in the expanded state:

This is what it looks like on large screens:

You can see a demo I created in CodePen at http://codepen.io/ricardozea/pen/fd504cbcf362069320d15a4ea8a88b27.

In the Toggle pattern, when the hamburger icon is tapped or clicked, the navigation bar slides down and the links are stacked. The navigation bar collapses when the hamburger icon is tapped again.

The HTML is as follows:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
</head>
<body>
    <!-- Hamburger icon -->
    <button class="menu-link"><span>Menu</span></button>
    <!-- Navigation -->
    <nav id="menu" class="menu" role="navigation">
        <ul>
            <li><a href="#">Link 1</a></li>
            <li><a href="#">Link 2</a></li>
            <li><a href="#">Link 3</a></li>
            <li><a href="#">Link 4</a></li>
            <li><a href="#">Link 5</a></li>
        </ul>
    </nav>
    <!-- Main container -->
    <main class="main-container" role="main">
        <h1>The Toggle Navigation</h1>
        <p>On <strong>small screens</strong>, the menu is triggered with a hamburger icon. The menu slides down/up.</p>
        <p>On <strong>large screens</strong> starting at 40em (640px), the menu is a horizontal nav.</p>
    </main>
</body>
</html>

The SCSS is as follows:

*, *:before, *:after { box-sizing: border-box; }
//Mobile-first Media Query Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content; }
}
//General Styling
.main-container, .menu {
    width: 98%;
    max-width: 980px;
    margin: auto;
    padding: 20px;
    background: #eee;
}
//Link that triggers the menu
.menu-link {
//Change to float: left; if you want the hamburger menu on the left side
    float: right;
    margin: 0 1% 5px 0;
    padding: 1.5em 1em 1em;
    background: #f6f6f6;
    line-height: 0;
    text-decoration: none;
    color: #333;
    border-radius: 2px;
    cursor: pointer;
    //Hamburger icon
    &:before {
        display: block;
        padding: 10px 0;
        content: '≡';
        font-size: 3em;
        line-height: 0;
    }
    //Active hamburger icon
    &.active {
        background: #333;
        color: #fff;
    }
    //Hide the term 'Menu' from displaying without sacrificing accessibility
    span {
        display: inline-block;

		text-indent: -100%;
        overflow: hidden;
        white-space: nowrap;
    }
    //On large screens hide the menu trigger
    @include forLargeScreens(640) {
        display: none;
    }
}
//If JavaScript is available, hide the menu.
.js .menu {
    overflow: hidden;
    max-height: 0;
    @include forLargeScreens(640) {
        max-height: inherit;
    }
}
//Menu itself
.menu {
    padding: 0;
    clear: both;
    transition: all .3s ease-out;
    //Define height of the menu
    &.active {
        max-height: 17em;
    }
    //Normalize the unordered list and add a bit of styling
    ul {
         margin: 0;
         padding: 0;
         list-style-type: none;
         border: 1px #999 dotted;
         border-bottom: none;
         text-align: center;
         //In large screens remove the border
        @include forLargeScreens(640) {
            background: #fff;
       }
    }
    //List items
    li {
      //Links themselves
      a {
         display: block;
         padding: 1em;
         border-bottom: 1px #999 dotted;
         text-decoration: none;
         color: #2963BD;
         background: #fff;
         @include forLargeScreens(640) {
            border: 0;
            background: none;
         }
      }
      //On large screens make links horizontal
      @include forLargeScreens(640) {
    display: inline-block;
    margin: 0 .20em;
       }
    }
}

//Styling stuff not needed for demo
body { font-family: Arial, "Helvetica Neue", Helvetica, sans-serif; }
p { line-height: 1.5; }
h1 { margin: 0; }

The jQuery is as follows:

$(function() {
    //Add class .js to the body if JS is enabled
    $("body").addClass("js");
    //Set up the click behavior
    $(".menu-link").click(function() {
        //Toggle the class .active on the hamburger icon
        $(this).toggleClass("active");
       //Toggle the class .active on the menu to make it slide down/up
        $(".menu").toggleClass("active");
    });
});

Let's take a look at the screenshots.

Here is what it looks like on small screens in the collapsed state:

And here is the expanded state:

Here is what it looks like on large screens:

You can see a demo I created in CodePen at http://codepen.io/ricardozea/pen/e91a5e6ea456d41f4128d9bd405ccaa0.

You can also visit http://responsive-nav.com/ for a nice Toggle navigation functionality.

This custom solution using Flexbox is incredibly versatile and it doesn't necessarily require the use of media queries. The other two menu solutions (Toggle navigation and Off-Canvas navigation) do require media queries.

With this solution, the menu items adapt to the available space, making the target zones as large as possible, automatically enhancing the usability of the menu. Another major plus of this Flexbox-based solution is that it's not JavaScript dependent.

This is the HTML:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
    <nav role="navigation">
        <ul class="menu">
            <li><a href="#">Link 1</a></li>
            <li><a href="#">Link 2</a></li>
            <li><a href="#">Link 3</a></li>
            <li><a href="#">Link 4</a></li>
            <li><a href="#">Link 5</a></li>
        </ul>
    </nav>
    <!-- Main container -->
    <main class="main-container" role="main">
        <h1>The Flexbox-based Navigation</h1>
        <p>On both <strong>small and large screens</strong> the menu and its items are always visible.</p>
        <p>However, on <strong>small screens</strong> the links are more clearly defined and occupy all the available space.</p>
   </main>
</body>
</html>

And now the SCSS:

*, *:before, *:after { box-sizing: border-box; }
//Mobile-first Media Query Mixin
@mixin forLargeScreens($media) {
    @media (min-width: $media/16+em) { @content; }
}
//Menu itself
.menu {
    display: flex;
    flex-wrap: wrap;
    justify-content: space-around;
    max-width: 980px;
    margin: auto;
    padding: 2px;
    list-style: none;
    border: #999 1px dotted;
    //List items
    li {
        //Expand to use any available space
        flex-grow: 1;
        margin: 3px;
        text-align: center;
        flex-basis: 100%;
        @include forLargeScreens(320) {
            flex-basis: 30%;
        }
        @include forLargeScreens(426) {
            flex-basis: 0;
        }
        //Links themselves
        a {
           display: block;
           padding: 1em;
           color: #2963bd;
           text-decoration: none;
           background: #eee;
           @include forLargeScreens(426) {
              background: none;
           }
        }
    }
}
//Main Container
.main-container {
    max-width: 980px;
    margin: auto;
    padding: 20px;
    background: #eee;
}

//Styling stuff not needed for demo
body { margin: 8px; font-family: Arial, "Helvetica Neue", Helvetica, sans-serif; }
p { line-height: 1.5; }
h1 { margin: 0; }

Let's take a look at the screenshots.

Here is what it looks like on small screens (320px):

Here is what it looks like on small screens (426px):

Here is what it looks like on a large screens (980px):

You can see a demo I created in CodePen at http://codepen.io/ricardozea/pen/022b38c6c395368ec4befbf43737e398.

When to use <picture> and when to use srcset? This is a very legit question that I myself couldn't wrap my head around when first heard these terms. So I decided to ask Brad Frost at a workshop he conducted in Dayton, OH.

The recommended approach boils down to this concept: art direction. In responsive images, art direction basically means that you have different images that are cropped a certain way so that less important parts of the image are left out in order to focus on the important ones.

This is different from just resizing the same image. Granted, you can use whatever method you want, but to keep things simple, you can use the <picture> element when you want to serve art directed images and the srcset attribute when you just want to serve resized versions of the same image.

Before we dive into the markup, let's see a visual example of an art directed image versus a resized image using the photo of the Kung Fu grandmasters:

Let's see what happened here. The original image has a lot of space around the Kung Fu grandmasters: we can see the trees and the buildings in the back. The resized versions maintain all aspects and proportions 1:1 of the original image.

However, the art directed images have a lot of differences. The first art directed image is cropped to show both grandmasters in a close up; the second art directed image has been cropped even more to accentuate the focus on Shi DeRu only (the grandmaster on the left). We could've cropped the image to focus on Shi DeYang (the grandmaster on the right), but this was the "art direction" I wanted to give the image. This is a subjective decision but based on a solid intent.

Now, let's see the Picturefill polyfill/script in action.

The first thing we need to do is download the JavaScript file, which can be downloaded from https://github.com/scottjehl/picturefill/blob/2.3.0/dist/picturefill.min.js

Then, all we need to do is include it in the <head> section of our document:

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <script src="js/picturefill.min.js"></script>
    <title>Picturefill polyfill</title>
</head>

When using the <picture> element, you (the author) tell the browser which image to use at which breakpoint. The good thing about this is that we can define exactly when a certain image should be displayed by using media queries. The media queries work exactly the same as the media queries used in CSS, and they even look exactly the same.

This is what a basic <picture> snippet looks like:

<picture>
    <source srcset="images/grandmasters-small.jpg" media="(max-width: 40em)">
    <source srcset="images/grandmasters-medium.jpg" media="(max-width: 64em)">
    <source srcset="images/grandmasters-default.jpg">
    <img src="images/grandmasters-default.jpg" alt="Fallback image">
</picture>

Now, even with a polyfill, IE9 has issues with the <picture> element. As weird as it sounds, we need to inject a <video> tag within conditional comments for IE9 to work correctly.

This is what the markup looks like after amending it for IE9:

<picture>
    <!--[if IE 9]><video style="display: none;"><![endif]-->
    <source srcset="images/grandmasters-small-ad.jpg" media="(max-width: 40em)">
    <source srcset="images/grandmasters-medium-ad.jpg" media="(max-width: 64em)">
    <source srcset="images/grandmasters-default.jpg">
    <!--[if IE 9]></video><![endif]-->
    <img src="images/grandmasters-default.jpg" alt="Fallback image">
</picture>

As you can see, I also highlighted the <img src="grandmasters-default.jpg" alt="Fallback image"> tag. This is the fallback image for those browsers that do not support the <picture> element.

One thing to keep in mind is that not so long ago, this fallback image caused double download in some modern browsers. My last tests showed that this was not the case in Chrome and Firefox, which do support the <picture> element. So make sure you run all necessary tests to see where you stand and then think of a solution if you need to support those legacy browsers.

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/cf6c0965785d552bad5e200acb761ffe

The srcset and sizes attributes actually come from the <picture> specification, but are implemented in the <img> element. When using the srcset and sizes attributes, the browser does all the work of deciding which image to use for each specific circumstance. You can also use media queries if you want, although, not required. The word vw means viewport width and it's used to let the browser know that it should display an image at a certain percentage in relation to the width of the viewport. If you see something like 80vw, it means that the image should be 80 percent of the width of the current viewport.

The w descriptor means the width of the image. If you see something like 255w, it means the browser will understand that specific image is 255px wide.

Let's take a look at an <img> tag with the srcset and sizes attributes:

<img src="images/grandmasters-default.jpg"
     srcset="images/grandmasters-small-rsz.jpg 255w,
             images/grandmasters-medium-rsz.jpg 511w"
     sizes="(min-width: 30em) 80vw, 100vw"
     alt="Mastering RWD with HTML5 and CSS3">

The letters rsz are an abbreviation of the word resize. That's because for images that are just going to be resized in RWD, the srcset attribute keeps things a bit simpler.

The following markup is truncated in order to focus on the specific explanations easily.

The first thing we see is the already known src attribute which acts as the fallback image:

<img src="images/grandmasters-default.jpg"…

Keep in mind that the image grandmasters-default.jpg will not be used by browsers that do understand srcset. In other words, the default image in browsers that support srcset is going to be first image in the list. In our case, it is grandmasters-small-rsz.jpg. Then, we see the srcset attribute.

This is where the magic starts happening:

srcset="images/grandmasters-small-rsz.jpg 255w,images/grandmasters-medium-rsz.jpg 511w"

In this example, our plan is to show two different image files in browsers that support srcset. This is accomplished by listing the images separated by commas. Also, the value defined after each image is the width of the image:

images/grandmasters-small-rsz.jpg 255w

grandmasters-small-rsz.jpg 170h

Giving the size of the image to the browser will allow it to make a more informed decision about what image to use based on the media query in the sizes snippet:

sizes="(min-width: 30em) 80vw, 100vw"

Remember, 30em is the same as 480px. With the media query min-width: 30em, the browser goes through the following process:

The last part of the sizes attribute is the viewport widths: 80vw, 100vw.

sizes="(min-width: 30em) 80vw, 100vw"

This means that if the viewport is 30em (480px) or less, the browser will show the image at 80 percent width. If it's more than 30em (480px), it will show the image at 100 percent width.

Finally, we have the alt attribute:

alt="Mastering RWD with HTML5 and CSS3">

Adding an alt attribute is always a good accessibility practice for users with assistive technology. Also, in case the images aren't loaded, browsers can display this text instead.

<img src="images/grandmasters-default.jpg"
     srcset="images/grandmasters-small-rsz.jpg 1x,images/grandmasters-medium-rsz.jpg 2x">

Some web designers and developers say that using media queries inside HTML like we saw with <picture> and srcset goes against the principle of separation of concerns: styling and markup should always remain as separated, independent assets.

Others, as I mentioned before, think that a new HTML element is unnecessary and that any solutions should be based on enhancing and extending already existing elements like the <img> tag.

All I can say is that at the end, none of that matters. What matters is that as web designers and developers, we should be using anything we have at our disposal to make users happy and create memorable experiences, while adhering to the best practices for long lasting implementations.

Using the script couldn't be any simpler. We need to download the script from https://github.com/imulus/retinajs/blob/master/dist/retina.min.js

Then, we place the script at the bottom of the HTML, right before the closing <body> tag:

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Retina.js - JavaScript Solution</title>
</head>
<body>
   ...
   <script src="js/retina.min.js"></script>
</body>
</html>

Then, we add an image to our markup:

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1"><meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Retina.js - JavaScript Solution</title>
</head>
<body>
   <img src="images/grandmasters-default.jpg" alt="">
   <script src="js/retina.min.js"></script>
</body>
</html>

That's it! We don't have to do anything to the markup, unless we want to exclude an image from being replaced. I explain how to do this coming up next.

The basic function of the JavaScript solution of Retina.js is that it looks for images in the page and replaces them with high-resolution versions if they exist on the server.

You need to name your high-resolution images with the @2x modifier right at the end of the name.

In other words, if you have the following image:

<img src="images/grandmasters-default.jpg" alt="">

Retina.js replaces it with the following one:

<img src="images/grandmasters-default@2x.jpg" alt="">

As long as the @2x image exists on the server, Retina.js replaces it. If the image doesn't exist, then it won't replace it.

<img src="images/grandmasters-default.jpg" alt="" data-no-retina>

Well, this is weird—a JavaScript solution that somehow also happens to have a CSS solution? Sweet! Note that this Sass mixin is for applying background high-resolution images.

The Sass mixin looks like this:

@mixin at2x($path, $ext: "jpg", $w: auto, $h: auto) {
    $at1x_path: "#{$path}.#{$ext}";
    $at2x_path: "#{$path}@2x.#{$ext}";

  background-image: url("#{$at1x_path}");

    @media all and (-webkit-min-device-pixel-ratio : 1.5),
        all and (-o-min-device-pixel-ratio: 3/2),
        all and (min--moz-device-pixel-ratio: 1.5),
        all and (min-device-pixel-ratio: 1.5) {
          background-image: url("#{$at2x_path}");
          background-size: $w $h;
  }
}

The usage is quite simple:

.hero {
    width: 100%;
    height: 510px;
    @include at2x('../images/grandmasters-default', jpg, 100%, auto);
}

We need to declare the file extension, the width, and the height as comma-separated values. The preceding Sass snippet will compile to this:

.hero {
    width: 100%;
    height: 510px;
    background-image: url("../images/grandmasters-default.jpg");
}
@media all and (-webkit-min-device-pixel-ratio: 1.5), all and (-o-min-device-pixel-ratio: 3 / 2), all and (min--moz-device-pixel-ratio: 1.5), all and (min-device-pixel-ratio: 1.5) {
    .hero {
        background-image: url("../images/grandmasters-default@2x.jpg");
        background-size: 100% auto;
    }
}

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/c3af015b325da6ee56cf59e660f3cc03

YouTube is an amazing video service that makes life easier for everyone—video authors, as well as web designers and developers. The fact that YouTube takes care of the hosting of the video, the streaming, and the technological conditions of browsers that don't support Flash (iOS), or browsers that don't support the <video> tag (legacy browsers), is just awesome.

The first thing we need to do is create a container that will hold the video. This container is the one we're going to manipulate to give the video the width we want while maintaining its aspect ratio:

<div class="video-container"></div>

Then, we create a container for the video we're going to embed:

<div class="video-container">
   <div class="embed-container"></div>
</div>

Then we embed the video, which is inside the <iframe> element:

<div class="video-container">
    <div class="embed-container">
        <iframe width="560" height="315" src="https://www.youtube.com/embed/vpRsLPI400U" frameborder="0" allowfullscreen></iframe>
    </div>
</div>

Ok, that's it for our markup. Now, let's tackle the CSS from inside out.

Let's give the <iframe> element a few properties:

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

Then, let's give the .embed-container wrapper some context:

.embed-container {
    position: relative;
    padding-bottom: 56.25%;
    padding-top: 35px; /* This padding is only needed for YouTube videos */
    height: 0;
    overflow: hidden;
}

Now the <iframe> element will be positioned correctly and take up all the space of its parent container. The parent container will make sure the video is visible and anything sticking out of it will be hidden.

All we need to do now is define the width of the whole thing. We do that by adding a width to the outer container, the .video-container wrapper:

.video-container {
    width: 80%; /* This can be any width you want */
}

If you're a jQuery fan, this plugin is for you. It may also come in handy when you have to retrofit already published videos on your site, or if there are too many of them to update manually.

The plugin is called FitVids.js. It was developed by Chris Coyer and the guys at Paravel. Using FitVids.js is pretty straightforward. First, we need to download the FitVids JavaScript file from the following URL: https://github.com/davatron5000/FitVids.js/blob/master/jquery.fitvids.js

Then, we call jQuery and the FitVids.js files in the <head> of our document. Finally, we add a script at the bottom of our markup to call the fitVids function. That's pretty much all there is to it.

Here's an HTML snippet with two videos within <iframe>, one from YouTube and another one from Vimeo:

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
<script src="js/jquery.min.js"></script>
<script src="js/jquery.fitvids.js"></script>
    <title>Responsive Videos with: jQuery Using FitVids.js</title>
</head>
<body>
    <h1>Responsive Videos with: jQuery Using FitVids.js</h1>
    <main class="main-container" role="main">
        <h2>YouTube</h2>
        <iframe width="560" height="315" src="https://www.youtube.com/embed/vpRsLPI400U" frameborder="0" allowfullscreen></iframe>
        <h2>Vimeo</h2>
        <iframe width="560" height="315" src="https://player.vimeo.com/video/101875373" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
    </main>
    <script>
        $(function(){
        //Look for all the videos inside this element and make them responsive
         $(".main-container").fitVids();
      });
   </script>
</body>
</html>

If you're curious about how FitVids.js modifies the DOM to make the videos responsive, here's the markup:

<div class="fluid-width-video-wrapper" style="padding-top: 56.25%;">
    <iframe src="https://www.youtube.com/embed/vpRsLPI400U" frameborder="0" allowfullscreen="" id="fitvid0"></iframe>
</div>

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/9e994c213c0eeb64ccd627e132778a42.

If you are not using jQuery or don't want any framework dependencies, but still need a simple JavaScript solution, the best option is to use a script developed by Todd Motto: Fluidvids.js.

Using it is very simple as well. First, we need to download the Fluidvids JavaScript file: https://github.com/toddmotto/fluidvids/blob/master/dist/fluidvids.min.js

Then, we need to call the fluidvis.js file in the <head> element of our document. Once we have that in place, we add a small script snippet at the bottom of our markup. That's it. The script will read through the markup, modify the DOM, and make any videos it finds responsive.

Here's the HTML snippet you'll need for this to work:

<!DOCTYPE html>
<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <script src="js/fluidvids.min.js"></script>
    <title>Responsive Videos with: Plain JavaScript - FluidVids.js</title>
</head>
<body>
    <h1>Responsive Videos with: Plain JavaScript - FluidVids.js</h1>
    <main class="main-container" role="main">
        <h2>YouTube</h2>
        <iframe width="560" height="315" src="https://www.youtube.com/embed/vpRsLPI400U" frameborder="0" allowfullscreen></iframe>
        <h2>Vimeo</h2>
        <iframe width="560" height="315" src="https://player.vimeo.com/video/101875373" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
    </main>
    <script>
        fluidvids.init({
            selector: ['iframe'],
            players: ['www.youtube.com', 'player.vimeo.com']
        });
    </script>
</body>
</html>

Here's the modified DOM:

<div class="fluidvids" style="padding-top: 56.2%;">
    <iframe src="https://www.youtube.com/embed/vpRsLPI400U" width="560" height="315" frameborder="0" allowfullscreen class="fluidvids-item" data-fluidvids="loaded"></iframe>
</div>

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/fda7c2c459392c934130f28cc092dbbe

What can I say? All you need to do is point your browser to http://embedresponsively.com/ and select the tab of the video service you want to use. Let's choose Vimeo. Input the URL of the video you want to make responsive, press the Embed button, and voilà—the HTML and CSS that you need to use appears right below the example video.

Here are the HTML and CSS snippets produced by embedresponsively.com for a video with the well-known Dan Mall about RWD (it has been formatted for easier reading):

The HTML is as follows:

<div class='embed-container'>
    <iframe src='https://player.vimeo.com/video/101875373' frameborder='0' webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
</div>

The CSS is as follows:

.embed-container {
    position: relative;
    padding-bottom: 56.25%;
    height: 0;
    overflow: hidden;
    max-width: 100%;
}
.embed-container iframe,
.embed-container object,
.embed-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}

However, with the following snippets, the container of the video looks much higher than it should be. In order to make the preceding snippets work properly, we need to wrap the embed-container inside an outer container. Here are the amended markup and CSS.

The HTML is as follows:

<div class="video-container">
    <div class='embed-container'>
        <iframe src='https://player.vimeo.com/video/101875373' frameborder='0' webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
   </div>
</div>

The CSS is as follows:

.video-container {
    width: 100%;
}
.embed-container {
    position: relative;
    padding-bottom: 56.25%;
    height: 0;
    overflow: hidden;
    background: red;
}
.embed-container iframe,
.embed-container object,
.embed-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
     height: 100%;
}

The .video-container wrapper is what we manipulate in order to define any width we want while maintaining the aspect ratio of the video. Now, all we need to do is place the markup in our HTML document and the CSS snippet in our SCSS file.

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/10262216eeb01fc9d3b3bedb9f27c908

When people ask what the difference between vectors and bitmaps/raster images is, the answers I often hear are usually around the idea, "If you enlarge it, it won't lose its quality. No worries for mobile devices." Although true, it doesn't fully answer the question. So here are the differences:

A vector image is a file made out of mathematical equations. The results of these equations are represented by a graphic (lines, shapes, colors). If the size of the image changes in any way, the values of those equations are recalculated and the resulting graphic is painted again.

A bitmap or raster image is a file made out of pixels. These pixels have a specific/defined width, height, and color. If an image is enlarged, the pixels are stretched and that's why the image looks blurry or pixelated.

With those definitions out of the way, let's talk about some of the vector formats used for RWD. Vector formats include:

Let's see how to rapidly implement icon fonts and SVGs; web fonts will be addressed in the next chapter.

Icon fonts are basically a font file but instead of having letters as glyphs it has, well, icons. Some people love icon fonts (I do), and some aren't really too fond of them, especially since SVG has gained so much popularity.

Let's see the pros and cons of icon fonts.

Some advantages are:

Some disadvantages are:

Here are a few recommendations I can give you when using icon fonts:

Let's implement an icon font then.

Implementing icon fonts

The fastest way to get icon font files is by using a third party web app like IcoMoon.io or Fontello.com. You can also get a copy of Font Awesome.

Tip

Be careful when considering using Font Awesome. Using a full font file with tenths of icons only to use a fraction of them is wasted bandwidth. If you're only going to use a handful of icon fonts, using IcoMoon.io or Fontello.com for custom icon selection is a better option.

Once you are able to unzip the provided files, the only file you're going to need is the .woff file. The reason you only need this file is because browser support for .woff files goes all the way back to IE9. Unless you want/need to support legacy browsers (desktop and mobile), you can then use .eot, .ttf, and .svg files.

Tip

I recommend that you keep it simple and avoid unnecessary headaches when trying to support icon fonts in legacy browsers. All they get is the text instead of the icon, or display the text in the title="" attribute.

Let's name our icon font file icon-font.woff. Create a /fonts folder and save the icon-font.woff file in it. This is what we are going to try to accomplish: a soft-blue link with an icon on the left, no underline, and 40px Arial/Helvetica font:

Using a pseudo-element

The great thing about using a pseudo-element is that our source markup always stays clean. In this case, we're going to use the :before pseudo-element, but this technique also works with an :after pseudo-element.

Let's take a look at the build.

This is the HTML snippet:

<a href="#" class="icon icon-headphones" title="Headphones">Headphones</a>

Here's the SCSS. The first thing we need is a mixin to handle any custom web fonts. In this case, it is an icon font:

//Web font mixin
@mixin fontFace($font-family, $file-path) {
    @font-face {
        font: {
            family: $font-family;
            weight: normal;
            style: normal;
        }
    src: url('#{$file-path}.woff') format('woff');
    }
}

Tip

Notice the nested properties in the font: {…} block. By doing this, we keep things DRY and avoid repeating the term font for the following instances: font-family, font-weight and font-style.

Then, we create a rule using attribute selectors to handle the basic styling properties of the icon font:

//Icon Font specific rule
[class^="icon-"], [class*=" icon-"] {
    font: {
        family: icon-font, Arial, "Helvetica Neue", Helvetica, sans-serif;
        weight: normal;
        style: normal;
        variant: normal;
    }
    text-transform: none;
    line-height: 1;
    speak: none;
    // Improve Font Rendering
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}

Tip

Notice the ^ and * characters in the attribute selectors. The first one means select elements starting with the term icon- and the second select elements containing the term icon-.

Then, we need to call the fontFace mixin in order to bring the font into the compiled CSS file:

@include fontFace(icon-font, '/fonts/icon-font');

The great thing about the fontFace mixin is that all we need to do is declare the font name and then the file path. There is no need to declare the file extension; that's taken care of by the mixin.

This will compile to:

@font-face {
    font-family: icon-font;
    font-weight: normal;
  font-style: normal;
  src: url("/fonts/icon-font") format("woff");
}

Here is the rule that makes the magic happen using :before:

.icon-headphones:before {
    content: "\e601";
    margin-right: 10px;
}

For basic styling enhancement, we create these other two rules. However, they are not required. The code is as follows:

.icon { font-size: 40px; }

a {
    padding: 5px;
    text-decoration: none;
    color: #2963BD;
    transition: .3s;
    &:hover { color: lighten(#2963BD,20); }
    &:focus { outline: 2px solid orange; }
}

The final compiled CSS looks like this:

[class^="icon-"], [class*=" icon-"] {
    font-family: icon-font, Arial, "Helvetica Neue", Helvetica, sans-serif;
    font-weight: normal;
    font-style: normal;
    font-variant: normal;
    text-transform: none;
    line-height: 1;
    speak: none;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}
@font-face {
    font-family: icon-font;
    font-weight: normal;
    font-style: normal;
    src: url("https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/icon-font.woff") format("woff");
}

.icon-headphones:before {
    content: "\e601";
    margin-right: 10px;
}
.icon {
    font-size: 40px;
}
a {
    padding: 5px;
    text-decoration: none;
    color: #2963BD;
    -webkit-transition: .3s;
        transition: .3s;
}
a:hover {
    color: #6d9adf;
}
a:focus {
    outline: 2px solid orange;
}

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/e62b201350efe7f59f91c934f9fc30fa

Here's another demo I created in CodePen with the icon fonts a bit more advanced: http://codepen.io/ricardozea/pen/5a16adffb6565312506c47ca3df69358

Using an extra HTML element

To be honest, using an extra HTML element goes a little against the principle of separating content from styling, since adding an extra HTML element for styling reasons is not something some developers recommend. However, we can also argue that the icon itself really is content, not styling. Either way, here's the run down.

Here's the HTML snippet:

<a href="#" title="Headphones"><i class="icon-headphones" aria-hidden="true"></i>Headphones</a>

Tip

In order to hide irrelevant content from screen readers, we use the aria-hidden="true" directive.

The SCSS code from the previous example is practically the same, except we move the font-size: 10px; declaration from the .icon class to the a rule and then delete the .icon class altogether. You will also see some extra properties but only for styling reasons.

The final SCSS looks like this:

//Web font mixin
@mixin fontFace($font-family, $file-path) {
    @font-face {
        font: {
        family: $font-family;
        weight: normal;
        style: normal;
    }
    src: url('#{$file-path}.woff') format('woff');
    }
}
//Icon Font specific rule
[class^="icon-"], [class*=" icon-"] {
    font: {
        family: icon-font, Arial, "Helvetica Neue", Helvetica, sans-serif;
        weight: normal;
        style: normal;
        variant: normal;
    }
    text-transform: none;
    line-height: 1;
    speak: none;
    // Improve Font Rendering
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}
@include iconFont(icon-font, '/fonts/icon-font');
.icon-headphones:before {
    content: "\e601";
    margin-right: 10px;
}
a {
   font-size: 40px;
    //Styling stuff
    padding: 5px;
    text-decoration: none;
    color: #2963BD;
    transition: .3s;
    &:hover { color: lighten(#2963BD,20); }
    &:focus { outline: 2px solid orange; }
}

The compiled CSS looks like this:

[class^="icon-"], [class*=" icon-"] {
    font-family: icon-font, Arial, "Helvetica Neue", Helvetica, sans-serif;
    font-weight: normal;
    font-style: normal;
    font-variant: normal;
    text-transform: none;
    line-height: 1;
    speak: none;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}

@font-face {
    font-family: icon-font;
    font-weight: normal;
    font-style: normal;
    src: url("https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/icon-font.woff") format("woff");
}
.icon-headphones:before {
    content: "\e601";
    margin-right: 10px;
}

a {
    font-size: 40px;
    padding: 5px;
    text-decoration: none;
    color: #2963BD;
    -webkit-transition: .3s;
          transition: .3s;
}
a:hover {
    color: #6d9adf;
}
a:focus {
    outline: 2px solid orange;
}

Here's a demo I created for this in CodePen: http://codepen.io/ricardozea/pen/8ca49cb06aeb070f4643f0a8e064126c.

SVG graphics have gained incredible popularity very quickly. Browser support is 100 percent, even Opera Mini supports SVG images. Let's discuss some pros and cons of SVG images:

The pros of SVGs:

The cons of SVGs:

An SVG file is basically an XML-formatted file. This is what the markup of the headphones graphic looks like:

<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 32 32">
        <path id="left-ear-pad" d="M9 18h-2v14h2c0.55 0 1-0.45 1-1v-12c0-0.55-0.45-1-1-1z"/>
    <path id="right-ear-pad" d="M23 18c-0.55 0-1 0.45-1 1v12c0 0.6 0.5 1 1 1h2v-14h-2z"/>
        <path id="headband" d="M32 16c0-8.837-7.163-16-16-16s-16 7.163-16 16c0 1.9 0.3 3.8 1 5.464-0.609 1.038-0.958 2.246-0.958 3.5 0 3.5 2.6 6.4 6 6.929v-13.857c-0.997 0.143-1.927 0.495-2.742 1.012-0.168-0.835-0.258-1.699-0.258-2.584 0-7.18 5.82-13 13-13s13 5.8 13 13c0 0.885-0.088 1.749-0.257 2.584-0.816-0.517-1.745-0.87-2.743-1.013v13.858c3.392-0.485 6-3.402 6-6.929 0-1.29-0.349-2.498-0.958-3.536 0.62-1.705 0.958-3.545 0.958-5.465z"/>
</svg>

There are many ways to use SVG images: inline via the <img>, <object>, <use>, or <svg> tags; as background images with CSS; using Modernizr in conditional classes to address fallbacks; or with jQuery or plain JavaScript, using third-party services such as grumpicon.com, you name it.

To keep things simple, we're going to focus on two methods:

<a href="#">
    <svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 32 32">
        <path id="left-ear-pad" d="M9 18h-2v14h2c0.55 0 1-0.45 1-1v-12c0-0.55-0.45-1-1-1z" />
    <path id="right-ear-pad" d="M23 18c-0.55 0-1 0.45-1 1v12c0 0.6 0.5 1 1 1h2v-14h-2z" />
        <path id="headband" d="M32 16c0-8.837-7.163-16-16-16s-16 7.163-16 16c0 1.9 0.3 3.8 1 5.464-0.609 1.038-0.958 2.246-0.958 3.5 0 3.5 2.6 6.4 6 6.929v-13.857c-0.997 0.143-1.927 0.495-2.742 1.012-0.168-0.835-0.258-1.699-0.258-2.584 0-7.18 5.82-13 13-13s13 5.8 13 13c0 0.885-0.088 1.749-0.257 2.584-0.816-0.517-1.745-0.87-2.743-1.013v13.858c3.392-0.485 6-3.402 6-6.929 0-1.29-0.349-2.498-0.958-3.536 0.62-1.705 0.958-3.545 0.958-5.465z"/>
    </svg>Headphones
</a>

svg {
    width: 40px;
    height: 40px;
    margin-right: 10px;
    fill: #2963BD;
}
a {
    font-size: 40px;
    text-decoration: none;
    color:#2963BD;
}

<a href="#">
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="32" height="32" viewBox="0 0 32 32">
        <path d="M9 18h-2v14h2c0.55 0 1-0.45 1-1v-12c0-0.55-0.45-1-1-1z"/>
        <path d="M23 18c-0.55 0-1 0.45-1 1v12c0 0.6 0.5 1 1 1h2v-14h-2z"/>
        <path d="M32 16c0-8.837-7.163-16-16-16s-16 7.163-16 16c0 1.9 0.3 3.8 1 5.464-0.609 1.038-0.958 2.246-0.958 3.5 0 3.5 2.6 6.4 6 6.929v-13.857c-0.997 0.143-1.927 0.495-2.742 1.012-0.168-0.835-0.258-1.699-0.258-2.584 0-7.18 5.82-13 13-13s13 5.8 13 13c0 0.885-0.088 1.749-0.257 2.584-0.816-0.517-1.745-0.87-2.743-1.013v13.858c3.392-0.485 6-3.402 6-6.929 0-1.29-0.349-2.498-0.958-3.536 0.62-1.705 0.958-3.545 0.958-5.465z"/>
        <foreignObject>
            <img src="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/headphones.png" alt="Headphones">
        </foreignObject>
    </svg>Headphones
</a>

<a href="#">
    <svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 32 32">
        <path id="left-ear-pad" d="M9 18h-2v14h2c0.55 0 1-0.45 1-1v-12c0-0.55-0.45-1-1-1z" />
        <path id="right-ear-pad" d="M23 18c-0.55 0-1 0.45-1 1v12c0 0.6 0.5 1 1 1h2v-14h-2z" />
        <path id="headband" d="M32 16c0-8.837-7.163-16-16-16s-16 7.163-16 16c0 1.9 0.3 3.8 1 5.464-0.609 1.038-0.958 2.246-0.958 3.5 0 3.5 2.6 6.4 6 6.929v-13.857c-0.997 0.143-1.927 0.495-2.742 1.012-0.168-0.835-0.258-1.699-0.258-2.584 0-7.18 5.82-13 13-13s13 5.8 13 13c0 0.885-0.088 1.749-0.257 2.584-0.816-0.517-1.745-0.87-2.743-1.013v13.858c3.392-0.485 6-3.402 6-6.929 0-1.29-0.349-2.498-0.958-3.536 0.62-1.705 0.958-3.545 0.958-5.465z"/>
        <image src="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/headphones.png" xlink:href="" alt="Headphones">
    </svg>Headphones
</a>

<img src="images/headphones.svg" alt="Headphones">

<a href="#">
    <svg width="39" height="39">
        <image xlink:href="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/headphones.svg" src="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/headphones.png" width="39" height="39">
    </svg>Headphones
</a>

The recommended way to define this first number is to use the body text size, that is, the font size that is used in the paragraphs. But keep in mind that using the body text size as the first base number is not mandatory. We can use our typeface's x-height, or some other length within that typeface, that we think could be a good starting point.

Although we can choose any font size, let's start with the default one we all know all browsers use, 16px. So we type 16px in the first base field.

Click on the plus icon and add a second base field.

The second base field is what I call a magic number because this number is completely subjective and arbitrary, however, it's tightly related to the project we're working on.

When I say tightly related I mean something like using the width of the main container, for example, 960px, 980px, 1140px, and so on. Alternatively, it can also be the number of columns used in the grid, such as 12 or 16. It can also be the width of a column at the maximum width of the site, such as 60px, or even the gutter spacing, say 20px.

This magic number is anything we want it to be, but it's directly related to our project in one way or another. For this example, let's say we're going to target screens at a maximum width of 1280px, so our main container is going to have a maximum width of 1140px. So let's type 1140px in the second base field.

This is where the magic takes place. Choosing a ratio means that this ratio will be multiplied by the base numbers creating a scale of values that are proportionally related.

The ratios are based on musical scales, and in that list is the golden ratio (1.618) as well, if we decide to use it. From the Ratios dropdown, select 1:1.618 – golden section ratio.

That's it! We have now created our first Modular Scale.

The font sizes provided by this Modular Scale are totally harmonious because they are proportionate to each other based on relevant values that are directly related to our project:

Our typography now has a solid modular foundation, let's use it.