4 ms·

Using Feature Queries in CSS

70 points by dwaxe 10y ago

dccoolgai 10y ago
Ran into a funny situation with this the other week where IE 10 supports flexbox (sort of), but doesn't support @supports. So that can happen. But if you're OK sequestering "doesn't support @supports" browsers into the non-enhanced experience, it works great.
- Flimm 10y ago
  IE10 and IE11 have a large numbers of bugs in their flexbox implementation or only support the 2012 syntax, so this might actually be desirable. (Compatibility info from http://caniuse.com/#feat=flexbox http://caniuse.com/#feat=flexbox )
  - dccoolgai 10y ago
    Yeah, that's why I said "(sort of)". But in my case, the flexbox features I was using worked OK. I was actually fine with having IE10 see the "block layout" fallback (b/c if you use IE10 the web looks broken for you anyway, so you should be overjoyed that you get a layout that works even if it's not that fancy), but my marketing manager felt differently. Life.
dlbucci 10y ago
I've been wanting to use these in some of my CSS, but I had never considered the case where a browser supports a feature, but doesn't support `@supports`. My best guess is you'd need a three stage CSS file to support that: first, use the new feature, then `@supports not` the backup code, then `@supports` the new feature. Maybe I won't be using this for a while...
- talmand 10y ago
  No, you set default properties on your element. Then you have @supports to enhance that element if the properties you wish to use are supported. It's a far better solution than the silly hacks we had to do before.
  - rhizome 10y ago
    Progressive enhancement is back!
  - dbbk 10y ago
    @supports is pretty necessary when you're using backdrop-filter. For instance, you want a navigation bar translucent with blurring on browsers that support it, and a solid colour for others.
dvcc 10y ago
/* NOT IE */ @supports (@supports) {} IE does not support it so it's kind of pointless, no? If I ever actually make the user of a feature query, I would need to create a backup plan for everything and then another backup plan when that backup plan fails!
- talmand 10y ago
  No, that's exactly the point. If the browser doesn't support @support then it ignores the whole block and falls back to the regular CSS you've likely, or hopefully, already written. The article actually discusses this. It's a modern equivalent of the stupid hacks we had to do back in the day because of bad, or good in some cases, IE CSS implementations.
  - dvcc 10y ago
    No I get that but I now have to look at it three times. Say I am using some feature, f, then I have to go check the case where the browser supports @supports but not @supports(f), supports @supports(f) and does not support @supports, since the styling changes are not all in isolation. Now to make it even crazier say we have another feature f1 that somehow impacts the case of @supports(f). We'll need to check five different cases (@s(f) + @s(f1), !@s(f) + @s(f1), etc...). It seems like I might as well just find the minimum feature set I can use and just go ahead with that. Anything more and there would be too much mental work for me.
    - talmand 10y ago
      Well, if you are fine with the minimum feature set then start with that. Then use the @supports for the enhanced version to make things nicer for everything other than IE. Just don't check for browsers not supporting @support. To be fair, I haven't used it on a production site so far.
      - marcosdumay 10y ago
        If you are not fine with the minimum feature set, it is not the "minimum feature set" and the in-browser app that you are writing will not work with it. I get what is so compelling about it, but I don't think I've ever seen anybody use such things correctly in practice. At least not on the web.
ry_ry 10y ago
Isn't @supports slightly redundant, though? Unless you're avoiding a broken feature, CSS will simple cascade down with the first supported property by default. It's how we've handled browser prefixing, background gradients, wonky flexbox and pretty much everything since forever. Im sure it'll be an unpopular opinion, but whilst I can see some edge cases where you only want to apply certain ancillary css if your markup is going to be rendering in a certain way, I honestly can't think of many (any?) real world usecases where you're not pretty much frigging it to provide 2005-tier browser sniffing.
- sleazy_b 10y ago
  This is what the author herself says in the article. Specifically, that feature queries should be used when you only want to apply a set of styles if a given feature is supported.
  - ry_ry 10y ago
    But surely that is in itself counter to how css is supposed to work at a very fundamental level? If you want to render different content for different browsers, I'm not convinced that is a function of stylesheets, not should it be. If my layout needs extra padding or whatever if a div is a flexbox, rather than display:table, I would consider that to be an implementation issue rather than something I would want to cover with additional code. I might just be completely missing the point, but it feels like a bandaid.
    - untog 10y ago
      It's a total bandaid, but that's the point. If the browser lets you sanely style things with display:grid, then you can. But you can have a fallback for browsers that don't support it.

70 points by dwaxe 10y ago

Ran into a funny situation with this the other week where IE 10 supports flexbox (sort of), but doesn't support @supports. So that can happen. But if you're OK sequestering "doesn't support @supports" browsers into the non-enhanced experience, it works great.

Flimm 10y ago
IE10 and IE11 have a large numbers of bugs in their flexbox implementation or only support the 2012 syntax, so this might actually be desirable. (Compatibility info from http://caniuse.com/#feat=flexbox http://caniuse.com/#feat=flexbox )
- dccoolgai 10y ago
  Yeah, that's why I said "(sort of)". But in my case, the flexbox features I was using worked OK. I was actually fine with having IE10 see the "block layout" fallback (b/c if you use IE10 the web looks broken for you anyway, so you should be overjoyed that you get a layout that works even if it's not that fancy), but my marketing manager felt differently. Life.

dlbucci 10y ago

I've been wanting to use these in some of my CSS, but I had never considered the case where a browser supports a feature, but doesn't support `@supports`. My best guess is you'd need a three stage CSS file to support that: first, use the new feature, then `@supports not` the backup code, then `@supports` the new feature. Maybe I won't be using this for a while...

talmand 10y ago
No, you set default properties on your element. Then you have @supports to enhance that element if the properties you wish to use are supported. It's a far better solution than the silly hacks we had to do before.
- rhizome 10y ago
  Progressive enhancement is back!
- dbbk 10y ago
  @supports is pretty necessary when you're using backdrop-filter. For instance, you want a navigation bar translucent with blurring on browsers that support it, and a solid colour for others.

dvcc 10y ago

/* NOT IE */ @supports (@supports) {} IE does not support it so it's kind of pointless, no? If I ever actually make the user of a feature query, I would need to create a backup plan for everything and then another backup plan when that backup plan fails!

talmand 10y ago
No, that's exactly the point. If the browser doesn't support @support then it ignores the whole block and falls back to the regular CSS you've likely, or hopefully, already written. The article actually discusses this. It's a modern equivalent of the stupid hacks we had to do back in the day because of bad, or good in some cases, IE CSS implementations.
- dvcc 10y ago
  No I get that but I now have to look at it three times. Say I am using some feature, f, then I have to go check the case where the browser supports @supports but not @supports(f), supports @supports(f) and does not support @supports, since the styling changes are not all in isolation. Now to make it even crazier say we have another feature f1 that somehow impacts the case of @supports(f). We'll need to check five different cases (@s(f) + @s(f1), !@s(f) + @s(f1), etc...). It seems like I might as well just find the minimum feature set I can use and just go ahead with that. Anything more and there would be too much mental work for me.
  - talmand 10y ago
    Well, if you are fine with the minimum feature set then start with that. Then use the @supports for the enhanced version to make things nicer for everything other than IE. Just don't check for browsers not supporting @support. To be fair, I haven't used it on a production site so far.
    - marcosdumay 10y ago
      If you are not fine with the minimum feature set, it is not the "minimum feature set" and the in-browser app that you are writing will not work with it. I get what is so compelling about it, but I don't think I've ever seen anybody use such things correctly in practice. At least not on the web.

ry_ry 10y ago

Isn't @supports slightly redundant, though? Unless you're avoiding a broken feature, CSS will simple cascade down with the first supported property by default. It's how we've handled browser prefixing, background gradients, wonky flexbox and pretty much everything since forever. Im sure it'll be an unpopular opinion, but whilst I can see some edge cases where you only want to apply certain ancillary css if your markup is going to be rendering in a certain way, I honestly can't think of many (any?) real world usecases where you're not pretty much frigging it to provide 2005-tier browser sniffing.

sleazy_b 10y ago
This is what the author herself says in the article. Specifically, that feature queries should be used when you only want to apply a set of styles if a given feature is supported.
- ry_ry 10y ago
  But surely that is in itself counter to how css is supposed to work at a very fundamental level? If you want to render different content for different browsers, I'm not convinced that is a function of stylesheets, not should it be. If my layout needs extra padding or whatever if a div is a flexbox, rather than display:table, I would consider that to be an implementation issue rather than something I would want to cover with additional code. I might just be completely missing the point, but it feels like a bandaid.
  - untog 10y ago
    It's a total bandaid, but that's the point. If the browser lets you sanely style things with display:grid, then you can. But you can have a fallback for browsers that don't support it.