CSS Conditional Rules

CSS Conditional Rules , as the name implies, are conditional constructions that can be applied to CSS itself. They implement the check of support for properties by the current browser with the ability to group conditional expressions using the logical operators and , or and not . In this post I would like to tell, among other things, about the syntax of this CSS3 module and current support for its browsers.

What's new?

So, what is the qualitative difference between CSS Conditional Rules and, for example, conditional comments? I would single out two main ones:

• This is a test of support for the specified properties by the browser, and not a check of the name and version of the browser.
• this is the implementation of conditional constructions directly in CSS, so we can control the “flow of application” of CSS properties, rather than selecting in HTML-code which pre-prepared stylesheets for different browsers to connect; in other words, if we need to implement a property that is not supported by all the necessary browsers, we have a flexible tool for degradation.

But in practice?

The syntax is simple. For example, we have a font-size property in which we want to use the calc() function to calculate the font size, and as an argument to this function we want to pass an expression that calculates the font size from the font size of the root body element. But how many browsers support it today? Not much. And what to do with the rest? Using CSS3 conditions, the question will get this answer:

 body { font-size: 14px; } @supports (font-size: calc(1rem + 12px)) { h1 { font-size: calc(1rem + 12px); } } @supports not (font-size: calc(1rem + 12px)) { h1 { font-size: 26px; } } 

The example is redundant, but the logic is visible. The @supports rule precedes the conditional construction. A conditional expression is what is in parentheses, while parentheses are always required. We can combine conditional expressions with the operators and and or , and also deny expressions with not .

At the same time, in order to avoid situations when the condition that you have made can not be interpreted in a single way, it is necessary to group the conditions with the help of parentheses, this is clearer by example. Consider an example from the specification:

 /*   ! */ @supports (transition-property: color) or (animation-name: foo) and (transform: rotate(10deg)) { } 

It would seem that the syntax is correct, what is more? The problem is that this construction can be interpreted in different ways. What did we mean: do we need support [( transition or animation ) and ( transform )] or [( transition ) or ( animation and transform )]? Unknown. That is why we have to use parentheses just as I did just now, describing possible options. The following variants of the same code will be correct.

 @supports ((transition-property: color) or (animation-name: foo)) and (transform: rotate(10deg)) { } @supports (transition-property: color) or ((animation-name: foo) and (transform: rotate(10deg))) { } 

Well, when?

And now about the status of support at the moment. The specification itself is in the status of a working draft. In stable versions today no one supports it. On August 3, support for @supports appeared in Firefox 17.0a1, that is, it is now in the Firefox Aurora branch and will be in Beta somewhere in October. I haven’t heard anything about support for other browsers yet (maybe someone from the browser will tell you). In Firefox 17 itself, this option may be disabled in the settings if developers decide that the specification is not stable enough yet.

UPD: Opera 12.10 beta has added support for @supports.