In native CSS, can an @media block be written inside a style rule, and what do the declarations inside it apply to?

## The old shape Before nesting, `@media` was strictly an outer wrapper. A component's responsive behaviour had to be written as a second rule inside a media block, repeating the selector: ```css .card { padding: 1rem; } @media (width >= 40em) { .card { padding: 2rem; } } ``` In large sheets those blocks drift far from the base rule, and the selector is duplicated at every breakpoint. ## Nesting at-rules inside style rules CSS Nesting allows conditional group rules to appear inside a style rule: ```css .card { padding: 1rem; @media (width >= 40em) { padding: 2rem; } } ``` The declarations inside the nested `@media` apply to whatever the enclosing rule matches — `.card` itself, not its descendants — whenever the query evaluates true. The mental desugaring is that bare declarations inside a nested at-rule behave as though wrapped in `& { … }`: ```css .card { padding: 1rem; @media (width >= 40em) { & { padding: 2rem; } } } ``` Writing the `& { … }` explicitly is always safe and was required by some early implementations, so you will see it in older examples. ## Which at-rules The ones that make sense inside a style rule are the **conditional group rules**: - `@media` — viewport, media type, and feature queries, including the range syntax `(width >= 40em)`. - `@supports` — feature detection, e.g. `@supports (display: grid) { … }`. - `@container` — container queries, which evaluate against a named or nearest query container rather than the viewport. At-rules that define something rather than conditionally apply declarations — `@font-face`, `@keyframes`, `@import`, `@property` — are top-level constructs and do not belong inside a style rule. ## Style rules inside the nested at-rule A nested at-rule can contain full nested rules as well as bare declarations, and the two compose: ```css .card { display: block; @media (width >= 40em) { display: grid; & .title { grid-column: 1 / -1; } } } ``` At-rules can also nest inside one another, which is how you express "wide viewport *and* the feature is supported": ```css .gallery { @supports (display: grid) { @media (width >= 60em) { grid-template-columns: repeat(3, 1fr); } } } ``` Each layer of conditions must hold for the innermost declarations to apply — the conditions are effectively ANDed together. ## Specificity and the cascade are unaffected A nested `@media` changes *whether* a declaration applies, never how strongly it competes. `@media` contributes nothing to specificity, so within the same cascade layer and origin, the nested declaration wins over the base one for the ordinary reason: same selector, same specificity, later source order. That is why the nested override reads naturally — put the conditional value after the default and it takes over when the query matches. A consequence worth knowing: if you write the media block *before* the base declaration in the same rule, and both target the same property, the base declaration wins even when the query matches, because it comes later. Order matters exactly as it does between two top-level rules. ## Why it is worth using Keeping breakpoints next to the property they modify makes a component readable in one place and makes deletion safe — removing the component removes its responsive rules with it. The cost is that a stylesheet no longer has a single "breakpoints" section to scan, so a house convention (always the same query text, ideally via a custom media convention or a shared constant in the build) matters more. ## Watch the query, not the nesting One genuine gotcha: a nested `@media` still measures the **viewport**, not the element. If a component should react to the space it is given rather than the window, `@container` is the at-rule you want — nesting it inside the component rule looks almost identical but resolves against a query container instead. Container queries are recent, so check support before relying on them.