Site down, cached version: http://webcache.googleusercontent.com/search?q=cache:http://...

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.

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.

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

https://developer.mozilla.org/en-US/docs/Web/API/CSS/support...

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.

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.

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.

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

There are browsers out there, that has not been updated in several years, like my Nokia N9 (Microsft bought the company and killed it)

Traditionally perhaps, but as we've moved into the age of evergreen browsers things have picked up substantially. It's now feasible to start using new APIs weeks after they roll out, sometimes with a polyfill to fall back to.

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.

"@supports (-webkit-animation-name)" would actually test true in pretty much every modern browser. See 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.

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.

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)

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

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

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.

Although this is true, I've been bitten by issues where the browser 'supports' the feature, but it's still broken in comparison to other browsers, resulting in having to disable the feature for that given browser via browser detection. The most recent issue was `clip-path` in FF; it behaves _very_ weirdly compared to other browsers (Chrome, Safari).

IIRC the main difference between FF clip-path and others is that FF clip-path's basic shape support is disabled by default. I recently added rounded corner support for inset clip paths, so FF (nightly) should have it too.

Could you provide a specific example as to how it was broken?

I was trying to do something like,

    @supports (clip-path: inset(0 50px 0 50px)) {
      selector {
        clip-path: inset(0 5px 0 50px);
      }
    }

where the clip path was animated. The @supports block would run, but the clip-path property would give an invalid property error. There was additional code within the @supports block related to displaying the animation. I ended up having to detect FF so that I could disable it, since it behaved differently than Chrome/Safari which use the webkit prefix.

Were you using a vendor prefix by chance?

Yeah, there is a -webkit prefix there as well for Chrome and Safari, which it works fine in.

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.

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.

The only significant modern-ish browsers that don't have @supports are all versions of IE (not including Edge) and Safari 8. In Safari's case, any version of Mac OS that ran Safari 8 would have gotten a Safari 9 update. So IE 10 and 11 do present some challenges in that case, but it will be up to the developer to decide if the amount of traffic from those browsers is worth worrying about.

I wonder if this impacts any features that exist today.

It looks like @supports has been supported by everything but IE, and also the Android browser (not Chrome for Android) for a while [1].

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/@supports#B...

@supports will change your life, eventually.

Link to table of browsers supporting the feature: http://caniuse.com/#feat=css-featurequeries

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.