A key part of the development process is to ensure that our code works on those browsers we have to support. If we're lucky enough that this range of browsers is limited to newer offerings, then this is less of an issue.

For some developers, there will be a need to have to support older browsers; this is particularly true if the environment contains other browser-based applications that require use of these older browsers, and cannot be replaced.

To help get around this, we could use libraries such as Modernizr (http://www.modernizr.com), but a more efficient means is to use the CSS @supports directive. In short, this operates in a similar fashion to media queries; we can specify a backup property that is supported by all browsers, and cancel it out if we're using a browser that can support an enhanced property:

section {
  float: left;
}

@supports (display: -webkit-flex) or (display: flex) {
  section {
    display: -webkit-flex;
    display: flex;
    float: none;
  }
}

In the main, this is more likely to be useful for those who have to provide support for older versions of IE (given that other browsers have offered better support for some time). Ideally, we would look to persuade clients of the merits of not supporting older versions of IE (at least 8, and possibly 9). If we have to support them, this method coupled with the use of autoprefixer could prove very useful.

When it comes to providing support for legacy browsers, the biggest culprit is arguably Microsoft's IE. Whilst it has to be said that support in newer versions is improving, its popularity means that there are still enough old versions to warrant the need to provide support!

To their credit, Microsoft have announced that they no longer support IE8 to 10—this is a step in the right direction to help encourage users to upgrade, although it will be some time before these versions completely disappear from use.

So, if you still have to support old versions of IE, what can we do? A good solution to try out is the oldie pack of plugins; its name makes a reference to what some term oldIE, or those versions of IE that should have been consigned to history a long time ago!

This plugin, available from https://github.com/jonathantneal/oldie, is a wrapper for a host of plugins available within PostCSS; examples include the following:

The pack includes other plugins—to get a feel for what plugins are included, it's worth taking a look at the index.js file for the plugin pack; it will look something like this:

The beauty, though, is that we are not forced to use the oldie plugin in its entirety. If, by some quirk of fate, we've managed to create something that in the main avoids those CSS attributes that are likely to make oldIE choke, then we can opt to simply reference those plugins that we need to use instead.

This will, of course, depend on how much we've used—a more likely scenario is that we will end up needing to use all of the plugins, so it makes better sense to use oldie instead! Of course, we could always encourage our clients to drop oldIE—this might not be as simple as it sounds…

If we're lucky enough to have understanding clients—and chance would be a fine thing—then there is likely to be a task that we need to perform: remove any style hacks from our code that relate to browsers we no longer support. The removal of these hacks may be trivial if we only have a small style sheet; the reality is that it will likely be a long, manual process for larger sheets, which carries a risk of us missing hacks.

Instead, we can avail ourselves of a plugin, in the form of stylehacks; this works very well with the stylelint plugin we've already used in demos throughout this book. Available from https://github.com/ben-eb/stylehacks, the plugin uses hacks listed on http://browserhacks.com, and is a cinch to install—let's take a look at it in action:

Assuming we have a successful compilation, try opening the style.css file in a text editor—we will, of course, have the requisite source map directive at the foot of the code, but otherwise notice how it has removed the color hack:

The key to this process lies within this task in our Gulp file:

gulp.task('styles', function () {
  return gulp.src('src/*.css')
    .pipe(postcss([ stylehacks({browsers: 'last 1 version, > 10%'}) ]))
    .pipe(gulp.dest('dest/'));
});

In our Gulp file, we've added the browsers attribute—this tells stylehacks to remove any hacks that are not required for modern browsers or those that have more than 10% global usage. This setting is based on the Browserslist query list available from https://github.com/ai/browserslist—it's worth noting that this can be used for plugins such as Autoprefixer as well.

Although this is a simple plugin to use, there is one nagging question that kept coming back whilst researching for this book: how useful is this plugin in reality? For some, you may think I need my head examined, but there is a reason behind this—let me explain.

If you've spent any time developing with jQuery, then you should be aware that it has dropped support for IE6-8 from jQuery 2.x, and will only develop support for it within the 1.x branch. Much of the baggage within jQuery within the 1.x branch is based on catering for browser hacks; the biggest culprit for these hacks is IE!

At the time of writing, Microsoft have publicly stated that support for IE10 and below is being dropped (at least for Windows 8)—they will only support IE11 on the Windows 8.1 platform, plus their new browser, MS Edge.

Given that many of the hacks found in CSS are for IE (and that this also applies to jQuery), one can't but wonder if the stylehacks plugin will still remain useful within the not too distant future! We should also be asking ourselves if using hacks is a good design decision. Are we designing a problem for ourselves at a later date, or should we be reconsidering our original design, and perhaps revisiting whether we need to support older browsers with a dedicated style sheet, rather than introducing hacks in amongst code designed for more recent browsers?