Using Feature Queries in CSS | Hacker News Reader

Using Feature Queries in CSS

hacks.mozilla.org

70 pointsdwaxe17 comments

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

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.

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.

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.

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.

/* NOT IE */ @supports (@supports) { body > .main-content { display: none; } .browser-update-notification { display: block; } }

There you go !

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

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.

Progressive enhancement is back!

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

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.

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 )

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.

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.

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.

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.

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.

Reply on news.ycombinator.com