Media Query Range Syntax

The plain-language idea

The traditional way to target a width range in a media query is two separate conditions joined with and: one min-width check and one max-width check. It works, and every frontend developer has written it hundreds of times, but it has a real ergonomic cost. Two adjacent breakpoints defined this way are easy to get subtly wrong — leaving a 1px gap where neither range applies, or an overlap where both do — because the boundary has to be reasoned about twice, once as somebody else's max-width and once as this rule's min-width.

Media query range syntax lets you write the same comparison using the operators you'd already use in any programming language — <, <=, >, >= — applied directly to a media feature like width. A single condition can express a full range in one expression instead of two conditions stitched together with and.

This is genuinely a syntax-ergonomics win, not a new capability — every range query written with the new syntax could already be expressed with min-width/max-width. The value is that it reads the way the comparison actually works, and it's harder to get the boundary wrong.

See it in a real thing: a tablet-only breakpoint

/* Traditional min/max pairing */
@media (min-width: 768px) and (max-width: 1024px) {
  .layout {
    grid-template-columns: repeat(2, 1fr);
  }
}

/* Range syntax: the same comparison, written as a comparison */
@media (768px <= width <= 1024px) {
  .layout {
    grid-template-columns: repeat(2, 1fr);
  }
}

Both rules apply the same two-column layout between 768px and 1024px inclusive. The range version reads left-to-right as a single inequality chain — "768px is less than or equal to width, which is less than or equal to 1024px" — which is closer to how most developers already think about a breakpoint range, and there's no separate min-width/max-width pair to keep in sync when the breakpoint value changes later.

What people usually miss

Watch out

• This doesn't do anything min-width/max-width couldn't already do. It's the same underlying comparison, written more directly — don't oversell it in an interview or a PR description as a new layout capability, because it isn't one.
• The two forms are freely interchangeable, including mid-codebase. There's no requirement to migrate a whole stylesheet at once — range syntax and the traditional min/max pairing can coexist across different rules while a codebase transitions.
• Range syntax is newly available, so an @supports fallback (or sticking with min/max for code that must run on older browsers) is the honest move if broad legacy support genuinely matters for the project — check the actual support bar for the codebase's target browsers rather than assuming universal availability.
• The off-by-one risk it reduces is specifically the boundary-matching problem between adjacent breakpoints, not a general claim that range syntax queries are less likely to have bugs than min/max ones for any other reason.

Why this matters in interviews

"Why might a layout momentarily have no matching breakpoint at exactly 1024px?" is a real question testing whether a candidate can spot a min/max boundary gap or overlap — and range syntax comes up naturally as the more legible way to write (and review) the comparison that avoids that class of bug.