{"id":281839,"date":"2019-02-18T10:39:13","date_gmt":"2019-02-18T17:39:13","guid":{"rendered":"http:\/\/css-tricks.com\/?p=281839"},"modified":"2019-02-25T09:55:38","modified_gmt":"2019-02-25T16:55:38","slug":"how-supports-works","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/how-supports-works\/","title":{"rendered":"How @supports Works"},"content":{"rendered":"

CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media<\/code> query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports<\/code> and it looks like this:<\/p>\n

@supports (display: grid) {\r\n  .main {\r\n    display: grid;\r\n  }\r\n}<\/code><\/pre>\n
Why? Well, that’s a bit tricky. Personally<\/em>, I find don’t need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn’t understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I’m certainly not a it’s-gotta-be-the-same-in-every-browser kinda guy, but I’m also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn’t do anything drastic to destroy functionality.<\/p>\n
That said, @supports<\/code> certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations.<\/p>\n
<\/p>\n
A classic use case<\/h3>\n
The example I used in the intro is a classic one that you’ll see used in lots of writing about this topic. Here it is a bit more fleshed out:<\/p>\n
\/* We're gonna write a fallback up here in a minute *\/\r\n\r\n@supports (display: grid) {\r\n  .photo-layout {\r\n    display: grid;\r\n    grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));\r\n    grid-gap: 2rem;\r\n  }\r\n}<\/code><\/pre>\n
Nice grid! Repeating and auto-filling columns is a sweet feature of CSS grid<\/a>. But, of course, there are browsers that don’t support grid, or don’t support all the specific features of it that I’m using above there. <\/p>\n
For example, iOS shipped support for CSS grid in version 10.2, but iOS has had flexbox support since version 7. That’s a decent gap of people with older iOS devices that do support flexbox but not grid. I’m sure there are more example gaps like that, but you probably get the idea.<\/p>\n
\n
I was running on an older version of mobile safari and many many many many many sites were flat out broken that used grid<\/p>\n
I\u2019m waiting another year or so before messing about with it<\/p>\n
— David Wells (@DavidWells) February 6, 2019<\/a><\/p><\/blockquote>\n