
Using Feature Queries in CSS - dwaxe
https://hacks.mozilla.org/2016/08/using-feature-queries-in-css/
======
dvcc

      /* 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
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
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
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
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.

------
dlbucci
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
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.

~~~
dbbk
@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.

------
dccoolgai
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
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
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.

------
ry_ry
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
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
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
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.

