CSS Module 15
Feature queries and the newest conditional CSS interview questions
Interview questions on feature queries and the newest conditional CSS: warm-ups, then what each harder question tests and how a good answer starts.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher to mid
When do you write a fallback declaration, and when do you need an @supports block?
Answered in the lesson Feature queries and progressive enhancement
-
Fresher to mid
How is a container style query different from a size container query?
Answered in the lesson Container style queries and state queries
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Mid to senior
A banner has background-color: #c5f4f5; followed by a color-mix() of three custom properties. Firefox shows the mixed colour, but Chrome shows no background at all. Explain why the fallback did not work, fix it, and say how you would stop this kind of bug from shipping again.
- What it tests
- Parse-time and computed-value-time validity, why var() defeats fallback declarations, writing a precise @supports test, and preventing the class of bug with review rules and checks in more than one engine.
- First step
- Separate the two moments a declaration is checked. Without var(), the browser validates the value while parsing and drops what it cannot parse, so the earlier declaration survives. With var(), it keeps the declaration and validates the value only after the variables are filled in. Chrome does not support color-mix() with three colours, so the value fails after the fallback has already lost the cascade.
- Follow-ups
-
- Why is the background transparent, and what would color do in the same situation?
- Why must the @supports test use plain colours instead of the variables?
- How would you catch this in code review or in automated checks?
From the lesson Feature queries and progressive enhancement
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; nothing renews unless you choose to. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to staff
Your design system wants tooltips placed with anchor positioning that flip above their button when there is no room below. Part of your audience uses browsers that are two or three years old. How do you ship it so that nobody gets a broken tooltip, and how do you test every path?
- What it tests
- Layered progressive enhancement, choosing between fallback declarations, @supports and @import supports(), reading Baseline data, and testing fallback paths that no current test engine takes.
- First step
- Decide what each group of browsers gets, and make every layer usable on its own: plain help text where popover is unknown, a popover panel where anchor positioning is missing, and the anchored, flipping tip where both work. Then read the support data: popover is newly available, and position-area and position-try-fallbacks shipped in Chrome 129, Firefox 147 and Safari 26.
- Follow-ups
-
- Why do the anchor declarations belong in one @supports block?
- How do you test the lower layers when every engine in your test runner supports anchor positioning?
- When would you move the enhancement into its own file loaded with @import supports()?
From the lesson Feature queries and progressive enhancement
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
Design info, warning and success tones for a callout component with container style queries, so that a page section can set the tone for every callout inside it and a single callout can still choose its own. How do nested callouts behave, and when would you use classes or :has() instead?
- What it tests
- The nearest-ancestor rule, inheritance of custom properties, why a container cannot style itself, defaults for older browsers, and choosing between style queries, classes and :has().
- First step
- Put the value where the decision is made: a default --tone on :root, a section that sets it for everything inside, and a modifier class on a callout that overrides it. Then style an element inside each callout, never the callout itself, because a query reads the nearest ancestor of the element it styles.
- Follow-ups
-
- What does a callout with its own tone show when it sits inside a warning section?
- How do you make the callout's own border change if queries cannot style the container?
- What do browsers without style queries show, and how do you keep that acceptable?
From the lesson Container style queries and state queries
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A sticky header had container-type: inline-size for its narrow layout. Someone changed it to container-type: inline-size scroll-state to add a shadow while it is stuck. Chrome looks right, but in Firefox and Safari the narrow layout broke. Why, and how do you fix it without losing the shadow in Chrome?
- What it tests
- How browsers drop a declaration they cannot fully parse, fallback chains for property values, scroll-state container queries as an enhancement, and checking a change in more than one engine.
- First step
- Check the computed container-type in each browser. Firefox and Safari do not support the scroll-state value, so they drop the whole declaration, the header is no longer a size container, and every size query inside it stops matching. The narrow layout was the casualty, not the shadow.
- Follow-ups
-
- Why does the browser not keep the inline-size part of the value?
- How would you detect this before it ships?
- Is there a way to get a similar shadow in browsers without scroll-state queries?
From the lesson Container style queries and state queries
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes