6 ms·

The @supports CSS rule

124 points by callumlocke 10y ago

geostyx 10y ago
Site down, cached version: http://webcache.googleusercontent.com/search?q=cache:http://www.lottejackson.com/learning/supports-will-change-your-life http://webcache.googleusercontent.com/search?q=cache:http://...
- bluejekyll 10y ago
  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.
mapleoin 10y ago
https://web.archive.org/web/20161010115605/http://www.lottejackson.com/learning/supports-will-change-your-life https://web.archive.org/web/20161010115605/http://www.lottej...
tedmiston 10y ago
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 10y ago
  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.
  - tedmiston 10y ago
    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#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/CSS/@supports#B...
  - cmg 10y ago
    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.
  - 50CNT 10y ago
    @supports will change your life, eventually.
  - lucideer 10y ago
    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.
- ezekg 10y ago
  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).
  - tedmiston 10y ago
    Were you using a vendor prefix by chance?
    - ezekg 10y ago
      Yeah, there is a -webkit prefix there as well for Chrome and Safari, which it works fine in.
  - Manishearth 10y ago
    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?
    - ezekg 10y ago
      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.
- drivingmenuts 10y ago
  Link to table of browsers supporting the feature: http://caniuse.com/#feat=css-featurequeries http://caniuse.com/#feat=css-featurequeries
sapeien 10y ago
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 10y ago
  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 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - dom0 10y ago
      If v6 were widely deployed in the early 2000s, then the Windows botnet phase would have been so much worse, many other issues aside.
- z3t4 10y ago
  There are browsers out there, that has not been updated in several years, like my Nokia N9 (Microsft bought the company and killed it)
- SquareWheel 10y ago
  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.
wanda 10y ago
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.
pitaj 10y ago
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.
ErrantX 10y ago
Key question; are there a subset of these nextgen(?) css features supported in browsers that don't support @supports?
- herbst 10y ago
  Guess the idea is future css releases. But well i most likely wont use it ether.
achairapart 10y ago
Not mentioned, there is also a CSS.supports() method available in JS: https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports https://developer.mozilla.org/en-US/docs/Web/API/CSS/support...
- deleted 10y ago
  [deleted]
loserkiddo 10y ago
I am the king of the world
jessedhillon 10y 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.
- uryga 10y ago
  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)
JD557 10y ago
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.

124 points by callumlocke 10y ago

Site down, cached version: http://webcache.googleusercontent.com/search?q=cache:http://www.lottejackson.com/learning/supports-will-change-your-life http://webcache.googleusercontent.com/search?q=cache:http://...

bluejekyll 10y ago
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.

mapleoin 10y ago

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

tedmiston 10y ago

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 10y ago
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.
- tedmiston 10y ago
  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#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/CSS/@supports#B...
- cmg 10y ago
  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.
- 50CNT 10y ago
  @supports will change your life, eventually.
- lucideer 10y ago
  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.
ezekg 10y ago
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).
- tedmiston 10y ago
  Were you using a vendor prefix by chance?
  - ezekg 10y ago
    Yeah, there is a -webkit prefix there as well for Chrome and Safari, which it works fine in.
- Manishearth 10y ago
  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?
  - ezekg 10y ago
    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.
drivingmenuts 10y ago
Link to table of browsers supporting the feature: http://caniuse.com/#feat=css-featurequeries http://caniuse.com/#feat=css-featurequeries

sapeien 10y ago

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 10y ago
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 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - dom0 10y ago
    If v6 were widely deployed in the early 2000s, then the Windows botnet phase would have been so much worse, many other issues aside.
z3t4 10y ago
There are browsers out there, that has not been updated in several years, like my Nokia N9 (Microsft bought the company and killed it)
SquareWheel 10y ago
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.

wanda 10y ago

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.

pitaj 10y ago

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.

ErrantX 10y ago

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

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

achairapart 10y ago

Not mentioned, there is also a CSS.supports() method available in JS: https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports https://developer.mozilla.org/en-US/docs/Web/API/CSS/support...

deleted 10y ago
[deleted]

loserkiddo 10y ago

I am the king of the world

jessedhillon 10y 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.

uryga 10y ago
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)

JD557 10y ago

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.