Compass is a framework for Sass that helps us write CSS more efficiently. Compass has a massive library of mixins that we can use to leverage dealing with vendor prefixes.

The installation of Compass is outside the scope of this book, so we're going to focus on the basic usage to deal with vendor prefixes and will assume that it is already installed on your machines. Refer to the Compass site for detailed instructions on how to install it (http://compass-style.org/).

Once we have Compass installed, we need to import the specific module that contains the mixins we need.

Staying with the linear gradient example we used before, let's import Compass' images module into our SCSS file. Place this at the top of your main SCSS file:

@import "compass/css3/images";

Then, we can use the corresponding mixin:

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

This will compile to the following:

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);
}

There are a few new things here.

The first declaration uses a base64 embedded SVG file. This is because legacy IEs and old versions of Opera have issues rendering gradients so an SVG is their fallback. Dealing with these types of issues is completely unnecessary by today's standards:

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);
}

The background-size: 100%; parameter is used so that the embedded SVG covers the whole container. Again, dealing with something like this is just a waste of time. Moreover, our code keeps getting bloated trying to support old technology. Consider the next block of code:

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);
}

The third declaration is the old CSS linear gradient syntax that was supported only by Webkit browsers; more unnecessary code bloating in our file:

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);
}

The fourth and fifth declarations are basically for old Firefox, Chrome, and Safari versions:

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);
}

The last declaration is the proposed syntax without any vendor prefixes:

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);
}

As we can see, Compass is a very handy tool and it allows us to customize the output. However, this may end up being more work than necessary.

A few things to consider before concluding whether Compass is the best solution for us:

-prefix-free is a JavaScript file created by Lea Verou. When the script is called by the browser, it detects it and then adds that browser's specific prefixes to the CSS. The -prefix-free file is intelligent enough to determine which prefixes are needed and only inject those.

Using -prefix-free is simple. Just add a call the JavaScript file. As per Lea Verou's recommendation, it's best to include this script after the style sheets in order to reduce the Flash of Unstyled Content (FOUC).

You can visit the -prefix-free project at http://leaverou.github.io/prefixfree/.

Since our HTML is so short, we can follow the tip mentioned before:

<!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>

It's certainly tempting to use this method since calling a mere JavaScript file to deal with automating vendor prefixes sounds like the best idea ever.

Let's see a short list of things to consider before deciding to use -prefix-free:

With this list, we are now in a better position to make a more informed decision that will benefit the project, ourselves and our users.

Autoprefixer is a CSS postprocessor that uses the CanIUse.com database to append vendor prefixes to an already compiled CSS file.

The term postprocessor means that it processes the CSS after (post) it has been created. In other words, if we have an SCSS file called styles.scss, this file gets compiled into styles.css after we save it. At that moment, Autoprefixer takes that generated styles.css file, opens it, adds all the necessary vendor prefixes to each property and value, saves the file, and closes it. In addition, you can configure it to create a new separate file as well. Once this is done, we can use this file in our website/app.

The major advantage that this method has over any other automated vendor prefixing method is that it uses the CanIUse.com database; this means that as soon as a browser vendor no longer requires its prefix for a CSS property or value, all we need to do is run our CSS files through Autoprefixer and it will be up to date in seconds.

The major disadvantage of Autoprefixer is that it has so many ways to use it that it could be a bit overwhelming for some. To name a few, we can use it via the command line but we'd need to have Node.js installed first:

npm install --global autoprefixer
autoprefixer *.css

We can also use Autoprefixer with Compass, but we need to have Ruby installed first:

gem install autoprefixer-rails

We can use it with CodeKit on Mac and with Prepros or Koala App on Windows/Mac/Linux. We can also install plugins for Sublime Text, Brackets, or Atom Editor. There are Grunt and Gulp plugins as well.

Let's see a short list of things to consider before deciding to use Autoprefixer:

Autoprefixer can be downloaded from https://github.com/postcss/autoprefixer.

Yes, it's Pleeease with three e. Pleeease is also a CSS postprocessor like Autoprefixer and it also depends on having Node.js installed. It only runs via the command line, but it's actually quite simple. Pleeease uses Autoprefixer, which means that it uses the CanIUse.com database as well to define which CSS properties and/or values need prefixing.

Once Pleeease is installed, we need to create a configuration file (a JSON file) in which the most important thing we need to define is the source CSS file and the destination CSS file:

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

Once we have that configuration file set, we run this in the command line:

pleeease compile

Pleeease takes the style.css file, adds all necessary vendor prefixes, and creates styles.fixed.css, which is the file we use in production.

There are other important things that Pleeease does at this point:

If you're comfortable using the command line and JSON files, Pleeease can be a very useful part of your arsenal. If you prefer to stay away from the command line, that's fine too; there are other friendlier ways to automate vendor prefixing.

Here are a few things to consider before deciding if Pleeease is the way to go to automate vendor prefixing:

You can download Pleeease from http://pleeease.io/.

Emmet allows us to write CSS and HTML faster. It's a plugin for text editors such as Sublime Text, Coda, TextMate, and even Dreamweaver.

Emmet also helps us with vendor prefixing our CSS3 properties and values, which is what we're going to focus on in the following examples.

Once the Emmet plugin is installed in our favorite text editor, we type this in our SCSS file:

.selector-a {
    -trf
}

Then we press Tab on our keyboard and the code automatically gets changed to this:

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

All we need to do to add vendor prefixes is start our abbreviation with a dash (-). This tells Emmet that it needs to add the necessary vendor prefixes when hitting the key Tab.

Here are a few things to consider before deciding to use Emmet to automate vendor prefixing:

You can download Emmet from http://emmet.io/.

As we have seen, the previous methods for automating vendor prefixing are all over the place, from methods that are used via the command line and methods that make you find a specific module to import before being able to use to JavaScript solutions.

The most important of all the features mentioned is that Autoprefixer uses the CanIUse.com database. This is pretty much what we want to use, since all we need to do is write the CSS3 properties and values and forget about vendor prefixing altogether, leaving it to Autoprefixer and CanIUse.com to add them for us.

Fortunately, there are third-party applications out there that already come with Autoprefixer installed. This means we don't have to set anything via the command line, or install a plugin, or anything like that. Just install the app, activate the Autoprefixer checkbox, and off we go!

We mentioned several applications before: CodeKit, Prepros, and the Koala app. They all do basically the same things, but they excel in two things:

These two features have a huge impact on our workflow, allowing us to focus our energies on the important stuff, such as RWD and a better user experience.

However, there are a few things to consider before deciding if a third-party application is the best solution for vendor prefixing:

This book recommends that you use CodeKit, Prepros, or Koala apps to deal with vendor prefixes. These applications not only compile the SCSS files, but also automatically run them through Autoprefixer when saving those SCSS files.

So let's take a look at Prepros, which can run on the most popular operating systems such as Windows, Linux, and Mac.

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;
}

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;
}

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

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

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.

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:

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:

That's all there is to it.

Since we don't know where our content is going to break and we need an initial mixin that we can add values to as we build our responsive site/app, we're going to start with a few known, width-specific values. Understand that these values may very well change and many other values will be added to this mixin.

We're going to name this file _mediaqueries.scss. The media queries mixin looks like this:

//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; }
    }
}

This is how we use the mixin in our main SCSS file:

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

This is what the mixin compiles to:

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

In the media queries examples of this book, we're going to declare the width values in em units rather than pixels. This is because using em helps scale all values better, independent of the screen densities. Let's see what's happening here.

//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; }

This is the favorite of many frontend developers. This mixin is almost the same as the one we just saw; the difference is that instead of using specific widths and knowing that those widths will change and others will be added, this mixin uses abstract names for device-specific widths and usually there's an already defined list of breakpoints.

Here's what this mixin looks like:

//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; }
    }
}

This is how we use it:

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

And this is how it looks compiled:

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

Consider the following points before choosing the Named Media Queries method:

This is the recommended mixin to use when working with media queries, and it has the following advantages:

Now, considering that our recommendation is to let the content define the breakpoints, here's the mixin:

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

That's it—a mere three-line mixin. This is how we use it:

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

This is what it compiles to:

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

Now, you might be asking yourselves, "where did the em values come from?"

It's simple. We divide the desired width by 16. The reason we're dividing by 16 is because 16px is the default font size of all browsers. By doing this, we get our values in em units.

Consider the following examples if you want to use 16px as your default font size:

If you decide that your default font size is not going to be 16px but rather 18px, then the same process applies. Divide the desired width by 18px:

The choice is yours.