Prompt and scope
A cross-browser design system wants natural entry animations and view transitions where new CSS at-rules are supported, while preserving a static experience elsewhere. A 2026 Chrome Web UI update describes detecting specific at-rules inside @supports. Design a rollout that preserves first paint, accessibility, and theme consistency.
What the interviewer is testing
The interviewer is testing whether you separate syntax recognition from complete behavior, and whether you can design cascade layers, fallback, reduced-motion handling, server rendering, and monitoring. A strong answer avoids hard-coding browser names as capability tests.
Questions to clarify first
- Is the enhancement decorative, or does interaction depend on a transition completing?
- What is the minimum acceptable experience when the new rule is unsupported?
- How do
prefers-reduced-motion, high contrast, and keyboard operation take priority? - Must the rollout cover embedded WebViews, old browsers, and an SSR first paint?
30-second answer
“I would make the base layout, states, and interactions complete in default CSS, then add optional styles behind an at-rule capability query. Detection only decides whether to enable enhancement; it does not replace runtime state or accessibility checks, and reduced motion always wins. Older browsers get a stable no-animation path while capable browsers get transitions. I would validate a real browser matrix, visual regression, keyboard operation, and first-paint metrics before expanding.”
Step-by-step solution
1. Define the baseline experience
The default layer must include complete layout, focus styles, error feedback, and actionable states without relying on an animation-end event. Unmounts, route changes, and network failures must still reach the target state directly.
2. Separate capability from state
Keep at-rule support in the CSS capability layer and component states such as open or leaving in classes or attributes. A capability query answers whether the browser can parse a rule; state selection answers what the component should show now. They are not one browser branch.
3. Organize cascade and fallback
Load base rules first, then add enhancement rules inside @supports. Enhancement should override only optional properties; when parsing fails, the unknown block should be ignored without damaging base styles. Do not let enhancement reset critical base dimensions or colors.
4. Respect motion preferences
Within the enhancement layer, honor prefers-reduced-motion: reduce by shortening or disabling transitions, while keeping focus, close, and error feedback clear. Support for view transitions never overrides a user preference.
5. Cover SSR and WebViews
The first HTML should not wait for client detection. Render the baseline structure on the server and let the client add optional enhancement. Test embedded WebViews, older browsers, partial support, and disabled animation to rule out blank screens and layout shifts.
6. Verify and release
Build a browser and feature matrix, then run visual regression, keyboard and screen-reader checks, CLS/LCP comparisons, and sampled error logs. Canary one component or low-risk page first; if regressions or complaints rise, remove the enhancement switch and keep the baseline path.
Model answer
I would first implement a complete baseline layout, state model, and accessibility behavior without new syntax, then add optional animation behind an @supports at-rule query. The query checks parse capability; component state remains in classes or attributes, and reduced motion has higher priority. SSR emits baseline HTML, so a failed enhancement is ignored. Before release I would test old browsers, WebViews, SSR, keyboard operation, and visual regression while watching CLS/LCP and error feedback. Canary one component and disable only the enhancement switch if it fails.
Common mistakes
- Branching on browser names → user-agent drift and misclassification → query capabilities.
- Treating parsing support as full behavior → partial implementations differ → run a real browser matrix and regression suite.
- Letting enhancement override base dimensions → unsupported browsers break layout → override only optional properties.
- Ignoring reduced motion → users lose control → handle the media query again in the enhancement layer.
- Waiting for client detection before first paint → blank screens or shifts → SSR the baseline experience.
Follow-up questions and responses
Is @supports support enough to trust the feature?
No. It only says the parser accepts the condition. Verify the specific at-rule, event timing, and fallback path in target browsers.
Why not delete the old CSS?
New capabilities may be absent in WebViews, enterprise browsers, or assistive-technology environments. The baseline is a durable contract, while enhancement must be independently removable.
How do you test reduced motion?
Enable prefers-reduced-motion: reduce in automated and manual tests. Confirm that shortening or removing animation still leaves focus, state, and close operations clear.
When can enhancement become the default?
Only after target coverage, visual and accessibility regression, performance metrics, and error rates meet gates, with the baseline fallback still available.