Prompt and context
The design system wants to choose colors, spacing, and layout values inside a CSS property from style, media, or feature conditions. Explain if() evaluation, fallback, support detection, accessibility impact, and progressive enhancement rather than only showing CSS.
What the interviewer evaluates
- Understanding that if() is value-level conditional logic and returns the first true condition in source order.
- Correct use of else and handling a guaranteed-invalid result when no condition matches.
- Checking browser support, @supports, server rendering, and critical-layout fallback.
- Considering theme changes, printing, reduced motion, and accessibility validation.
Clarifying questions to ask
- Are conditions media, container/style, or feature queries? Which wins when several match?
- What legacy-browser value should the property use when no valid value is produced?
- Is this decorative color or critical layout affecting size, readability, and hit targets?
- Which browsers and WebViews are supported, and is a build-time CSS fallback available?
30-second answer framework
I would limit if() to properties with safe fallbacks, then define condition order and an else value. Conditions are evaluated in order and the first true value wins; with no match and no else, the result can be invalid and the property falls back. I would provide a static declaration and enable the enhancement behind @supports, then test themes, print, contrast, reduced motion, and older browsers. Critical layout would not depend on experimental syntax.
Step-by-step deep dive
1. Set the value-level boundary
Use if() to choose values for one property under CSS-observable conditions; do not replace selectors, a DOM state machine, or business logic. Keep JavaScript-only data out of a CSS condition.
2. Design order and fallback
Conditions are evaluated in source order, so put the most specific or important rule first and use else for a safe value. Without a match, the result may be guaranteed-invalid and the browser may use inheritance, an initial value, or no declaration; critical properties need an explicit legacy default.
3. Progressive enhancement and compatibility
MDN marks the function as limited-support experimental technology. Declare a static value first, then enable if() in @supports or a layered stylesheet; do not rely on user-agent strings alone. Server rendering supplies structure while the client validates style capability.
4. Validate experience and accessibility
Test real themes, viewports, printing, and feature combinations. Check contrast, focus visibility, hit targets, and prefers-reduced-motion. Track unsupported and fallback rates; disable the enhancement when critical layout drifts.
Model answer
I would treat if() as value-level progressive enhancement. I would identify style, media, or feature conditions, order them deliberately, and provide an explicit else safety value; an unmatched invalid result must not be left to browser guessing. Critical layout would have a static declaration and use if() only inside @supports, validated across real browsers and WebViews. I would test themes, print, contrast, focus, reduced motion, and combinations, monitor fallback and layout differences, and remove the enhancement if it harms the baseline.
Common mistakes
- Treating if() as JavaScript business logic or a selector replacement.
- Ignoring source order so a broad condition wins too early.
- Omitting else and a static default, leaving old browsers without critical styles.
- Using experimental syntax for dimensions, navigation, or hit targets without fallback.
- Testing only a current browser and skipping WebViews, print, and themes.
- Failing to check contrast, focus, and reduced motion.
Follow-up questions and responses
What happens when no condition matches?
Without else the result may be guaranteed-invalid, after which inheritance, an initial value, or an unset value applies. Critical properties need an acceptable static fallback.
Why is @supports alone insufficient?
It verifies parsing of a declaration, not that every condition combination and resulting value meets the design. Behavior still needs validation in target browsers, themes, and assistive technology.
When would you keep custom properties and multiple declarations?
Keep them when browser coverage is strict, conditions are few, or the fallback must be obvious to audit. Use if() only when the compatibility matrix makes its compact expression worthwhile.