Over the past year and a half, the CSS Working Group has been working on a CSS Conditional Rules Module Level 3 module. Now, don’t get overexcited: this is not a proposal to add generalized, formal if/then/else or switch statements to CSS — though in a very limited way, it does just that. This is the home of the @media rule, which lets you create if/then conditions with regard to the media environment. It’s also the home of the @supports rule, which lets you…well, that’s actually more complicated than you might think.
I mean, what do you think @supports means? Take a moment to formulate a one-line definition of your understanding of what it does, before moving on to the rest of this piece.
If you’ve never heard of it before and wonder how it works, here’s a very basic example:
body {background-color: white;}
@supports (background-color: cornflowerblue) {
body {background-color: cornflowerblue;}
}
The idea is that if the browser supports that property:value combination, then it will apply the rule or rules found inside the curly brackets. In this sense, it’s just like @media rules: if the conditions in the parentheses are deemed to apply, then the rules inside the declaration block are used. The module refers to this ability as “feature queries”.
There are some logical combination keywords available: and, or, and not. So you can say things like:
body {color: #222; background-color: white;}
@supports ((background-color: cornflowerblue) and (color: rgba(0,0,0,0.5))) {
body {background-color: cornflowerblue; color: rgba(0,0,0,0.5);}
}
Okay, but what does that actually mean? Here’s what the specification says:
A CSS processor is considered to support a declaration (consisting of a property and value) if it accepts that declaration (rather than discarding it as a parse error). If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration or claim support for it.
So in that first sentence, what we’re told is that “support” means “accepts [a] declaration” and doesn’t drop it on the floor as something it doesn’t recognize. In other words, if a browser parses a property:value pair, then that qualifies as “support” for said pair. Note that this sentence says nothing about what happens after parsing. According to this, a browser could have a completely botched, partial, and generally unusable implementation of the property:value pair, but the act of recognizing means that there’s “support”.
But wait! That second sentence adds an additional constraint, after a fashion: there must be “a usable level of support”, the lack of which means that a browser “must not…claim support”. So not only must a browser parse a property:value pair, but support it to “a usable level”.
But what constitutes a “usable level”? According to everyone who’s told me that I was wrong about vendor prefixes, any browser implementation of a feature should be complete and error-free. Is that what’s required to be regarded as a usable level? How about if the implementation has one known bug? Three? Ten? Can any of them be severe bugs? What about merely serious bugs? What if two browsers claim usable support, and yet are not interoperable?
So. How does the definition of @supports match the one-line definition I asked you to formulate, back at the beginning? Are they exactly the same, or is there a difference?
I suspect that most people, especially those coming across @supports for the first time, will assume that the word means that a browser has complete, error-free support. That’s the implicit promise. Very few people think of “supports” as a synonym for “recognizes” (let alone “parses”). There’s a difference, sometimes a very large one, between recognizing a thing and supporting it. I’m sure that browser teams will do their best to avoid situations where a property:value pair is parsed but not well supported, but it’s only a matter of time before a “supported” pair proves to be badly flawed, or retroactively made wrong by specification changes. Assuming that such things will be allowed, in an environment where @supports exists.
If feature queries were set with @feature, as media queries are set using @media, or even if the name were something along the lines of @parses or @recognizes, I’d be a lot less bothered. The implicit promise would be quite a bit different. What I feel like we face here is the exact inversion of vendor prefixes: instead of a marker for possible instability and a warning that preserves the possibility of changing the specification when needed, this pretends to promise stability and safety while restricting the WG’s ability to make changes, however necessary. My instinct is that @supports will end up in the same place: abused, broken, and eventually reviled — except this time, there will be the extra bitterness of authors feeling that they were betrayed.
