4 ms·
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 7
by 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 agoBut 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 agoI 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 agoThe 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 agoThis 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 agoAlthough 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 agoWere you using a vendor prefix by chance?
- ezekg 10y agoYeah, there is a -webkit prefix there as well for Chrome and Safari, which it works fine in.
- Manishearth 10y agoIIRC 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 agoI 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 agoLink to table of browsers supporting the feature: http://caniuse.com/#feat=css-featurequeries http://caniuse.com/#feat=css-featurequeries