Facilitating feature forks in CSS

When you're building out a responsive web design, attempting to provide a single design that works everywhere, on every device, it's a simple fact that you'll frequently encounter situations when features or techniques are not supported on certain devices. In these instances you'll likely want to create a fork in your CSS; if the browser supports a feature, provide one chunk of code, if they don't, they get different code. It's the kind of situation that gets handled by if/else or switch statements in JavaScript.

We currently have two possible approaches. One is entirely CSS based but with fewer browser implementations, and the other is only made possible with the help of a JavaScript library but enjoys far broader support. Let's consider each in turn.

Feature queries

The native solution to forking code in CSS is to use 'Feature Queries', part of the CSS Conditional Rules Module Level 3 (http://www.w3.org/TR/css3-conditional/). However, right now, CSS Conditional Rules lack support in Internet Explorer (as of version 11) and Safari (including iOS devices up to iOS 8.1) so support is hardly ubiquitous.

Feature queries follow a similar syntax to media queries. Consider this:

@supports (flashing-sausages: lincolnshire) {
  body {
    sausage-sound: sizzling;
    sausage-color: slighty-burnt;
    background-color: brown;
  }
}

Here the styles will only get applied if the browser supports the flashing-sausages property. I'm quite confident that no browser is ever going to support a flashing-sausages feature (and if they do, I want full credit) so none of the styles inside the @supports block will be applied.

Let's consider a more practical example. How about we use Flexbox for when browsers support it, and fallback to another layout technique when they don't. Consider this example:

@supports (display: flex) {
  .Item {
    display: inline-flex;
  }
}


@supports not (display: flex) {
  .Item {
    display: inline-block;
  }
}

Here we are defining one block of code for when the browser supports a feature, and another lot for when it doesn't. This pattern is fine if the browser supports @supports (yes, I realise that is confusing) but if it doesn't, it won't apply any of those styles.

If you want to cover off devices that don't support @supports, you're better off writing your default declarations first and then your @supports specific one after, so that the prior rule will be overruled if support for @support exists, and the @support block will be ignored if the browser doesn't support it. Our prior example could therefore be reworked to:

.Item {
  display: inline-block;
}

@supports (display: flex) {
  .Item {
    display: inline-flex;
  }
}

Combining conditionals

You can also combine conditionals. Let's suppose we only wanted to apply some rules if both Flexbox and pointer: coarse were supported (in case you missed it, we covered the 'pointer' interaction media feature back in Chapter 2, Media Queries – Supporting Differing Viewports). Here is what that might look like:

@supports ((display: flex) and (pointer: coarse)) {
  .Item {
    display: inline-flex;
  }
}

Here we have used the and keyword but we could use or as well as, or instead of it. For example, if we were happy to apply styles if those two prior property/value combinations were supported, or 3D transforms were supported:

@supports ((display: flex) and (pointer: coarse)) or (transform: translate3d(0, 0, 0)) {
  .Item {
    display: inline-flex;
  }
}

Note in that prior example, the extra set of parenthesis that separates the flex and pointer conditional from the transform conditional.

Sadly, as I already mentioned, support for @support is far from universal. Boohoo! What's a responsive web designer to do? Fear not, there's a great JavaScript tool that is more than capable of rising to this challenge.

Modernizr

Until @supports is more widely implemented in browsers, we can use a JavaScript tool called Modernizr. At present, it's simply the most robust manner in which to facilitate forks in your code.

When forks are needed in CSS, I try and adopt a progressive enhancement approach. Progressive enhancement means starting with simple accessible code; code that will provide, at the very least, a functional design for less capable devices. Then that code is progressively enhanced for more capable devices.

Tip

We'll talk a lot more about progressive enhancement in Chapter 10, Approaching a Responsive Web Design.

Let's look how we can facilitate progressive enhancement and forking our CSS code with Modernizr.

Feature detection with Modernizr

If you're a web developer, it's likely you have heard of Modernizr, even if you have perhaps not used it. It's a JavaScript library that you include in your page that feature tests the browser. To start using Modernizr, it's as simple as including a link to the downloaded file in the head section of your pages:

<script src="/js/libs/modernizr-2.8.3-custom.min.js"></script>

With that in place, when the browser loads the page, any of the included tests are run. If the browser passes the test, Modernizr handily (for our purposes) adds a relevant class to the root HTML tag.

For example, after Mondernizr has done its thing, the classes on the HTML tag for a page might look like this:

<html class="js no-touch cssanimations csstransforms csstransforms3d csstransitions svg inlinesvg" lang="en">

In that instance just a few features have been tested: animations, transforms, SVG, inline SVG, and support for touch. With those classes in place, the code can be forked like this:

.widget {
  height: 1rem;
}

.touch .widget {
  height: 2rem;
}

In the preceding example, the widget item is just 1rem high ordinarily, but if the touch class is present on the HTML (thanks to Modernizr), then the widget would be 2rem high.

We could flip the logic too:

.widget {
  height: 2rem;
}

.no-touch .widget {
  height: 1rem;
}

This way we would default to the item being 2rem high, and adjust down if the no-touch class was present.

Whichever way you want to structure things, Modernizr provides a widely supported way to fork features. You'll find it especially useful when you want to use features like transform3d but still provide a working substitute for browsers that can't make use of it.

Tip

Modernizr can provide accurate tests for most things you'll likely need to fork code on, but not all. For example, overflow-scrolling is notoriously difficult to accurately test for. In situations where a class of devices isn't playing happily, it may make more sense to fork your code on a different feature. For example, as older Android versions have difficulty with horizontal scrolling you might fork with no-svg (as Android 2-2.3 doesn't support SVG either).

Finally, you may wish to combine tests to make your own custom test. That's a little outside the scope here but if that's something that interests you, take a look at http://benfrain.com/combining-modernizr-tests-create-custom-convenience-forks/.

Previous Chapter

Word wrapping

Next Chapter

New CSS3 selectors and how to use them

Table of Contents for Responsive Web Design with HTML5 and CSS3 - Second Edition

Facilitating feature forks in CSS

Feature queries

Combining conditionals

Modernizr

Tip

Feature detection with Modernizr

Tip

Table of Contents for
Responsive Web Design with HTML5 and CSS3 - Second Edition