Why Use @supports Instead of Modernizr?

When Chris Mills published his dev.Opera article Native CSS feature detection via the @supports rule, @silvenon asked me "But wouldn't that be redundant? Modernizr already does a feature detection whether or not the browser is old."

The reason to use @supports over Modernizr is performance; functionality that's built into the browser will always be faster than adding it in script. Removing an external dependancy saves an HTTP request to download Modernizr and doesn't require time to execute the JavaScript.

This is one reason why Paul Irish has said "an upcoming release of Modernizr will defer to the results of @supports if @supports is supported".

So, for example, if you're only using Modernizr to test for CSS support, you could conditionally load the JavaScript library if @support isn't available in the user's browser:

<pre>if ( !(window.supportsCSS || (window.CSS && window.CSS.supports) )) load_modernizr()</pre>
(This release of Opera uses supportsCSS. After implementation, the spec was changed to CSS.supports instead, hence using both in the test above.)

You'd need to write two sets of rules, one using the classes applied by the Modernizr tests, the others using @supports blocks which, in time-honoured CSS fashion, are ignored by browsers that don't understand them. This makes your CSS larger, but saves an HTTP request and saves execution time.

Should you use Modernizr or @supports? The answer is definitively "it depends". As with all web projects, only you can decide which is the best way.