An Introduction to CSS’s @supports Rule (Feature Queries)

The two general approaches to tackling browsers’ uneven support for the latest technologies are graceful degradation and progressive enhancement.

Graceful degradation leverages advanced technologies to design for sophisticated user experiences and functionality. Users of less capable browsers will still be able to access the website, but will enjoy a decreased level of functionality and browsing experience.

With progressive enhancement, developers establish a baseline by designing for a level of user experience most browsers can support. Their applications provide built-in detection of browsers’ capabilities, which they use to make available more advanced functionality and richer browsing experiences accordingly.

The most widely adopted tool in a progressive enhancement approach is the Modernizr JavaScript library.

Modernizr programmatically checks if a browser supports next generation web technologies and accordingly returns true or false. Armed with this knowledge, you can exploit the new features in supporting browsers, and still have a reliable means of catering to older or noncompatible browsers.

As good as this sounds, something even better has been brewing for some time. You can perform feature detection using native CSS feature queries with the @supports rule.

In this post I’m going to delve deeper into @supports and its associated JavaScript API.

[author_more]

Detecting Browser Features with the @supports Rule

The @supports rule is part of the CSS3 Conditional Rules Specification, which also includes the more widespread @media rule we all use in our responsive design work.

While with media queries you can detect display features like viewport width and height, @supports allows you to check browser support for CSS property/value pairs.

To consider a basic example, let’s say your web page displays a piece of artwork that you’d like to enhance using CSS blending. It’s true, CSS blend modes degrade gracefully in non supporting browsers. However, instead of what the browser displays by default in such cases, you might want to delight users of non supporting browsers by displaying something equally special, if not equally spectacular. This is how you would perform the check for CSS blending in your stylesheet with @supports:

[code language="css"]
@supports (mix-blend-mode: overlay) {

.example {
mix-blend-mode: overlay;
}

}
[/code]

To apply different styles for browsers that don’t have mix-blend-mode support, you would use this syntax:

[code language="css"]
@supports not(mix-blend-mode: overlay) {

.example {
/* alternative styles here */
}

}
[/code]

A few things to note:

• The condition you’re testing must be inside parentheses. In other words, @supports mix-blend-mode: overlay { ... } is not valid. However, if you add more parentheses than needed, the code will be fine. For instance, @supports ((mix-blend-mode: overlay)) is valid.
• The condition must include both a property and a value. In the example above, you’re checking for the mix-blend-mode property and the overlay value for that property.
• Adding a trailing !important on a declaration you’re testing for won’t affect the validity of your code.

Let’s flesh out the examples above with a small demo. Browsers with mix-blend-mode support will apply the styles inside the @supports() { ... } block; other browsers will apply the styles inside the @supports not() { ... } block.

The HTML:

[code language="html"]
<article class="artwork">
<img src="myimg.jpg" alt="cityscape">
</article>
[/code]

The CSS:

[code language="css"]
@supports (mix-blend-mode: overlay) {

.artwork img {
mix-blend-mode: overlay;
}

}

@supports not(mix-blend-mode: overlay) {

.artwork img {
opacity: 0.5;
}

}
[/code]

Check out the demo on CodePen:

Continue reading %An Introduction to CSS’s @supports Rule (Feature Queries)%

by Maria Antonietta Perna via SitePoint