@supports Lies: When CSS Says 'Yes' But Browsers Say 'LOL No'

CSS @supports was supposed to be our safety net: check if a feature is supported, then apply a fallback. In reality, that net has more holes than a Swiss cheese. The browser cheerfully responds 'Yes, I support that' — and then proceeds to ignore it. Sound familiar? It's like a colleague saying 'deployed' while the CI pipeline is burning red.

The core issue is that @supports only checks syntactic support, not actual behavior. For example, a browser might know about backdrop-filter but fail to apply it due to disabled hardware acceleration or a bug. You get true, but on screen — a blurry mess. It's like buying shoes that fit in the store but pinch your toes after five minutes.

This bites hardest when you rely on @supports for progressive enhancement. You write: 'If grid is supported, use grid', and the browser says 'Yep, got it', then proceeds to break your layout. Thanks, Captain. A bug that makes you nostalgic for the good old IE6 days.

So what's the fix? Don't trust @supports blindly. Use CSS.supports() in JavaScript for runtime checks, or leverage libraries like Modernizr. And always test on real devices — not just in Chrome DevTools. Because browsers, as it turns out, have a sense of humor.

METABYTE studio comment: We've been burned by @supports too. Our motto now: 'Trust, but verify — especially with CSS.' If you want to avoid such surprises in your project, we know how to lay the straw.