Hacker News Reader

Comment by talmand | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com