Check
Ask if a declaration is supported.
Platform under construction
@supports
@supports lets CSS ask the browser whether a feature is available before applying advanced rules.
@supports (container-type: inline-size) {
.panel { container-type: inline-size; }
}
Production mental model
@supports is the safety switch for modern CSS.
The @supports rule is a feature query. It checks whether the browser understands a CSS declaration.
Use it to protect enhancements that depend on newer CSS. The fallback stays outside the block; the advanced version lives inside.
This keeps modern CSS usable without forcing every browser to understand every feature.
Fallback
Write normal CSS outside the block first.
Enhance
Put advanced CSS inside @supports.
Combine
Use not, and and or when needed.
Visual model
See the release risk before shipping the CSS.
.layout
Base CSS applies to everyone.
@supports
Browser evaluates the feature.
enhance
Modern CSS improves the component.
keep base
The fallback remains usable.
Good CSS versus fragile CSS
Feature query enhancement
.panel { width: min(100%, 42rem); }
@supports (container-type: inline-size) {
.panel-list { container-type: inline-size; }
}Feature query without fallback
@supports (container-type: inline-size) {
.panel { container-type: inline-size; }
.panel-card { grid-template-columns: subgrid; }
}Rules of thumb
Production CSS should be usable, fast, tested and repeatable.
Put fallback first
The page should work before the feature query runs.
Check declarations, not dreams
@supports tests whether a property-value pair is understood.
Use it for real risk
Do not wrap every normal declaration in @supports.
Keep enhancements scoped
Only the parts that need the feature belong inside the block.
Use not carefully
@supports not can create fallbacks, but base-first CSS is often clearer.
Test both paths
Temporarily change the condition to verify fallback and enhancement behavior.
Production thinking
The release is not finished until the edge cases are checked.
Why does this matter?
@supports lets you use modern CSS with confidence instead of waiting years for every browser edge case.
Accessibility
The fallback path must be accessible too. Do not put essential visibility, order or focus behavior only inside enhancement code.
Production note
Feature queries are best when they protect specific features that have real support risk.
SEO note
Fallback-first CSS keeps content visible and usable even without advanced feature support.
Live code lab
Change the CSS and watch the interface respond.
The preview runs in an isolated iframe. Links and forms stay inside the practice area, so you can experiment without leaving the lesson.
Mini assignment
Try this now.
- Change the condition to (display: fake-grid) and check the fallback.
- Move all CSS inside @supports and explain why that is risky.
- Add @supports not (display: grid) and compare it with fallback-first CSS.
Practice assignment
Do this before moving to the next lesson.
- Write one fallback layout.
- Add one @supports enhancement.
- Verify that both paths remain readable.
Try it yourself
Enhance a layout with @supports
Self-check
Before you continue, prove that you understand @supports.
Answer these questions before moving on. Production CSS is not about writing more rules; it is about proving the rules survive real use.
- Can you explain what @supports tests?
- Can you keep fallback CSS outside the block?
- Can you avoid wrapping normal CSS unnecessarily?
- Can you test the unsupported path?
- Can you keep essential content outside enhancement-only CSS?
Senior audit upgrade
@supports is for progressive enhancement.
Feature queries are useful when a modern feature improves the design but the baseline must still work.
Positive query
Use @supports (display: grid) for enhanced layouts.
Negative query
@supports not (...) can define fallback-specific fixes.
Do not overuse
If the baseline already works well, a feature query may add unnecessary complexity.