
The @supports CSS rule - callumlocke
http://www.lottejackson.com/learning/supports-will-change-your-life
======
geostyx
Site down, cached version:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.lottejackson.com/learning/supports-
will-change-your-life)

~~~
bluejekyll
This is ingenious front end design. Thank you for posting the cached version.

It does continue to prove that your backend is extremely important too.
Delivery is hard.

------
JD557
I like the fact that this exists, but it seems like the kind of hacks that go
against the philosophy of progressive enhancement.

The thing that I like about progressive enhancement is that it "forces" the
HTML documents actually represent the content. I should be able to render any
site (excluding web-apps, I guess) with CSS and Javascript disabled,
preferably with semantic HTML. This makes that site not only accessible to
humans, but machines as well.

I see a bunch of websites that have 2 versions of certain elements (for
example, navigation menus) in the HTML that are hidden with @media rules to
make the site "responsive". I'm scared that this @supports rule will be used
in the same way.

Disclaimer: I am not a frontend web developer, so my understanding of
progressive enhancement might be wrong.

------
achairapart
Not mentioned, there is also a CSS.supports() method available in JS:

[https://developer.mozilla.org/en-
US/docs/Web/API/CSS/support...](https://developer.mozilla.org/en-
US/docs/Web/API/CSS/supports)

------
sapeien
According to MDN, `@supports` is part of the CSS3 spec, defined in 2012. In
2016, it's time to start using it. Web development in a nutshell.

~~~
lucideer
IPv6 spec was 1996.

Four years is not really a very long time in the greater scheme of things, the
pace of modern web development just makes for an impatient populous with short
attention spans.

~~~
cyphar
I don't think that you can compare a backwards-incompatible change in a low
layer of the stack that runs the internet with a feature of CSS parsers that
was standardised 4 years ago. Some things are expected to take more time than
others.

~~~
dom0
If v6 were widely deployed in the early 2000s, then the Windows botnet phase
would have been _so much worse_ , many other issues aside.

------
wanda
While it's nice to not need Modernizr, or JavaScript at all, it's generally
only useful for features added _after_ the @supports support landed. As others
have mentioned, there's also the problem of false positives, and you could end
up with a lorra lorra @supports statements if you include vendor prefixing as
well — not a problem JavaScript has to put up with, because you can just
define a prefixing function and save many lines of code.

Here's the problem vis-á-vis compatibility. CSS Animations are supported back
to Safari 4; @supports landed in Safari 9.

For instance:

    
    
      @supports (-webkit-animation-name: blink){
        .cursor {
          -webkit-animation-name: onoff;
          -webkit-animation-duration: .9s;
          -webkit-animation-timing-function: cubic-bezier(.4,0,.2,1);
          -webkit-animation-iteration-count: infinite;
        }
      }
    
    

That's actually damaging, because there won't be a browser that supports
@supports _and doesn 't_ support CSS animation. This statement will activate
the animation only in Safari 9+, despite the feature enjoying support
beforehand. By conditioning the animation on support for _animation-name_ ,
we're actually preventing the feature from showing up where it ought to.

Of course, @supports is very useful for bleeding edge stuff like animation-
play-state, which just landed in Chrome (and I dare say Firefox) as a
byproduct of the Web Animations API.

 _animation-play-state_ let's us control whether an animation (let's say an
infinite one) is paused or playing. So, if you imagine a scrolling marquee
(for the sake of irony), for instance, you could conditionally pause the
marquee on hover by setting:

    
    
        @supports (animation-play-state: paused){
          .marquee:hover { 
            animation-play-state: paused
          }
        }
    

You may be thinking "that's effing ridiculous, I could just add that CSS
property anyway and if it's not supported it won't work, simple" — and you'd
be right to say so.

It would be equally pointless to write this:

    
    
        @supports (will-change: transform){
          .element { will-change: transform; }
        }
    

because if the property is not supported, it simply won't do anything, and it
will not affect anything else or prevent CSS parsing. @supports is pointless
as a mere wrapper because there's no need for containment.

However, @supports is not for applying potentially unsupported properties
only; it's for conditionally activating/altering entire aspects of your
website based on there being support for a _crucial_ feature.

More useful code might look like this example:

    
    
        @supports (animation-play-state: paused){
          .marquee {
            white-space: nowrap;
            animation-name: marquee;
            animation-duration: 20s;
            animation-timing-function: linear;
            animation-delay: 1s;
            animation-fill-mode: forwards;
            will-change: transform;
          }
          .marquee:hover {
            animation-play-state: paused;
          }
        }
    

This would be useful if, for instance, it would harm usability to have an
unstoppable marquee of images/products, so with this sort of code you could
have that marquee display as something more mundane, like a grid of items, and
if the ability to pause the animation is supported, then convert it into a
scrolling marquee gallery of items.

It's also potentially useful for things like _mix-blend-mode_ , if you want to
apply some kind of fancy effects with a fallback to a simple, one colour
overlay:

    
    
        .overlay {
          position: absolute;
          top: 0;
          left: 0;
          width: 100%;
          height: 100%;
          background: radial-gradient(rgba(31,10,25,.2), rgba(3,81,176,.6));
        }
    
        @supports (mix-blend-mode: difference){
          .overlay {
            mix-blend-mode: difference;
            background: radial-gradient(rgba(31,10,25,.2), rgba(176, 109, 3, 0.6));
          }
        }
    

See, if you wanted to apply the difference blending mode but have a similar
colour theme, the background of the overlay would need to be basically the
opposite, so you can use a @supports block to conditionally change the colour
to suit whatever the blending-mode requires.

~~~
bzbarsky
"@supports (-webkit-animation-name)" would actually test true in pretty much
every modern browser. See [https://compat.spec.whatwg.org/#css-simple-
aliases](https://compat.spec.whatwg.org/#css-simple-aliases)

But yes, your larger point that @supports is easy to misuse when targeting old
prefixed stuff is certainly true.

> animation-play-state, which just landed in Chrome (and I dare say Firefox)

animation-play-state has been supported unprefixed in Firefox since Firefox
16, 4 years or so ago.

------
mapleoin
[https://web.archive.org/web/20161010115605/http://www.lottej...](https://web.archive.org/web/20161010115605/http://www.lottejackson.com/learning/supports-
will-change-your-life)

------
jessedhillon
This seems like a reduction in readability from either declaring properties in
an order such that browsers which don't support the syntax will still have a
fallback declaration:

    
    
        .foobar {
          background: red;  /* fallback declaration */
          background: poorly-supported;  /* preferred declaration */
        }
    

or using platform-specific property prefixes.

Personally, I'd rather see the entire definition block for a selector in one
place than have to consult multiple conditional declarations.

~~~
uryga
yes, tbh it reminds me of #IFDEF. not entirely sure how i feel about that: it
_kinda_ makes sense but i think the fallback version is better. (unless the
css ends up really different, then the ifdef approach makes sense)

------
ErrantX
Key question; are there a subset of these nextgen(?) css features supported in
browsers that don't support @supports?

~~~
herbst
Guess the idea is future css releases. But well i most likely wont use it
ether.

------
tedmiston
Tl;dr - We can use @supports instead of Modernizr to check whether a browser
supports a particular CSS property. Though @supports itself is only supported
by 77% of browsers, in unsupported browsers, the @supports blocks are ignored
making them effectively supported everywhere. We can use this in production
today.

~~~
sdegutis
But if the requested _feature_ is supported in a given browser even though
_@supports_ isn't, it will act as though the feature is _not_ supported. That
seems like a major flaw.

~~~
lucideer
This will affect a small percentage of features, in a small percentage of
browsers, _of_ the 23% that don't support @supports (all three of which are
shrinking percentages).

That coupled with the fact the features are likely to be non-functional
aesthetic elements makes it a very minor flaw imo.

------
pitaj
This looks cool. But does anyone else think that the circular text wrapping
around the example image is super ugly? It makes it much less readable for me.

