3 ms·

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

• 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.
• Raphmedia 10y ago
  /* NOT IE */ @supports (@supports) { body > .main-content { display: none; } .browser-update-notification { display: block; } } There you go !