CSS compatibility: support, prefixes and strategy

Learn how to write resilient CSS with real fallbacks, `@supports`, vendor-prefix tooling and a progressive-enhancement mindset, so modern features improve the experience without breaking older environments.

How much do you know about CSS?

📘 Theory

The four ideas that matter most

Keep this mental model in mind whenever you adopt a new CSS feature.

`@supports` feature queries

They let you apply an enhancement only when the browser understands the property-value pair you depend on.

Vendor prefixes

Use tooling such as Autoprefixer instead of hand-writing prefixes unless you are solving a very specific edge case.

Progressive enhancement

Start with a working default, then upgrade the experience without putting the baseline at risk.

Real compatibility decisions

Use Can I Use, Browserslist and your actual audience data to decide what support target makes sense.

Using `@supports` as a decision layer

`@supports` checks whether the browser understands a concrete declaration before applying the enclosed rules. That makes it the native conditional system of CSS.

You can combine checks with `and`, `or` and `not` to model realistic support paths instead of creating messy overrides.

This is especially useful for upgrades such as `subgrid`, `backdrop-filter` or container queries, where the baseline layout must still work if the enhancement is unavailable.

Basic pattern: `@supports (display: grid) { ... }`
Negation: `@supports not (display: grid) { ... }`
Combined condition: `@supports (display: grid) and (gap: 1rem) { ... }`

Prefixes without turning your CSS into noise

Prefixes such as `-webkit-`, `-moz-` and `-ms-` still appear in some browser support stories, especially around older implementations or properties with an uneven rollout.

In production projects, the cleanest solution is usually Autoprefixer plus Browserslist. You write modern CSS, define your browser target, and let the tool generate only what is still necessary.

Remember that unsupported declarations are simply ignored. That is why fallbacks and declaration order still matter even when a build tool is helping you.

Autoprefixer adds the required prefixes automatically.
Browserslist defines the browsers you care about.
Hand-written prefixes should be the exception, not the default.

Progressive enhancement in real layouts

Begin with a version that is completely usable. For a card list, that might mean Flexbox with wrapping and comfortable spacing.

Then add the improved version with `@supports`: Grid, `subgrid`, visual blur or any more advanced enhancement that genuinely improves the interface.

If the browser cannot use the upgrade, it simply keeps the solid base. That is the real value of progressive enhancement: stability first, refinement second.