How Do CSS Custom Media Queries (@custom-media) Work?
Learn how CSS @custom-media defines named, reusable breakpoints, why it needs PostCSS today, and how it centralizes media conditions.
Expected Interview Answer
CSS custom media queries let you define a named, reusable media condition once with @custom-media --name (condition), and then reference it by name across your stylesheet with @media (--name), so a breakpoint value only has to be updated in one place instead of being duplicated in every @media rule.
Without custom media queries, a common breakpoint like (min-width: 768px) gets copy-pasted into dozens of @media rules across a codebase, so changing the breakpoint means a find-and-replace across every file, which is error-prone. @custom-media --tablet (min-width: 768px) defines that condition once as a named token, and every subsequent @media (--tablet) { ... } rule expands to the full condition at build or parse time, keeping breakpoints centralized the same way custom properties centralize values. Custom media queries can also be combined with logical keywords like and, or, and not, and can reference other custom media queries in their definition. As of now this feature is not yet supported natively by browsers and requires a PostCSS plugin (postcss-custom-media, part of postcss-preset-env) to compile it down to standard @media rules at build time, so it is a build-time authoring convenience today rather than a runtime browser feature — worth knowing the distinction between this and cascade layers or CSS custom properties, which do have native runtime support.
- Centralizes breakpoint values in one named definition instead of scattering literals
- Makes @media rules self-documenting by using semantic names like --tablet or --dark-mode
- Reduces the risk of breakpoint drift when one @media rule is updated but others are missed
- Can be composed from other custom media queries and combined with and/or/not
AI Mentor Explanation
Custom media queries are like a league defining "powerplay overs" once in the rulebook’s glossary — meaning exactly overs 1 through 6 — instead of writing "overs 1 through 6" out longhand in every single rule that references it. When the league later changes the powerplay window, only the glossary entry needs updating, and every rule that says "during powerplay" automatically reflects the new range. That define-once-reference-by-name pattern, resolved before the match rules are finalized, is exactly what @custom-media does for CSS breakpoints.
Step-by-Step Explanation
Step 1
Define the custom media query
@custom-media --tablet (min-width: 768px); declares a named, reusable condition.
Step 2
Reference it across the stylesheet
Use @media (--tablet) { ... } anywhere the breakpoint is needed instead of the raw condition.
Step 3
Compile with a PostCSS plugin
postcss-custom-media (via postcss-preset-env) expands named references into standard @media rules at build time.
Step 4
Update in one place when needed
Changing the breakpoint means editing only the @custom-media definition, not every usage site.
What Interviewer Expects
- Correct explanation of the define-once, reference-by-name mechanism
- Awareness that this requires a PostCSS build step, not native browser support
- Understanding of the maintainability win versus copy-pasted raw @media conditions
- Knowledge that custom media queries can be composed with and/or/not and other custom media queries
Common Mistakes
- Claiming @custom-media is natively supported by browsers today without a build tool
- Confusing @custom-media with CSS custom properties (--var), which are a different, natively-supported feature
- Not mentioning the maintainability benefit of centralizing breakpoints
- Forgetting that custom media queries can be combined with logical keywords like and/or/not
Best Answer (HR Friendly)
“Custom media queries let me name a breakpoint once, like tablet meaning min-width 768px, and then reuse that name everywhere instead of retyping the raw condition in every media query. If the breakpoint ever needs to change, I only update it in one place. It does require a small build tool since browsers do not support it natively yet.”
Code Example
/* defined once */
@custom-media --tablet (min-width: 768px);
@custom-media --desktop (min-width: 1200px);
/* referenced anywhere in the stylesheet */
.sidebar {
display: none;
@media (--tablet) {
display: block;
width: 240px;
}
@media (--desktop) {
width: 320px;
}
}Follow-up Questions
- How does @custom-media differ from CSS custom properties (--var)?
- What build tool is required to use @custom-media today, and why?
- How would you combine a custom media query with `and`/`not`?
- What happens if two @custom-media declarations use the same name?
MCQ Practice
1. What is the primary benefit of @custom-media over repeating raw @media conditions?
@custom-media lets you define a condition once and reference it by name, avoiding duplicated, drift-prone breakpoint literals.
2. How is @custom-media currently supported in browsers?
As of now, @custom-media needs a build-time tool like postcss-custom-media; it is not a native runtime browser feature.
3. Which CSS feature is @custom-media most often confused with?
Both use a similar --name syntax, but custom properties are natively supported values while custom media queries are conditions needing a build step.
Flash Cards
What does @custom-media do? — Defines a named, reusable media condition referenced via @media (--name) elsewhere.
Is @custom-media natively supported by browsers? — No — it requires a PostCSS plugin like postcss-custom-media at build time.
What is the main maintainability win? — Breakpoints are centralized in one definition instead of duplicated across many @media rules.
Can custom media queries be composed? — Yes — with and/or/not and by referencing other custom media queries.