Prompt and context
A design tool must zoom its canvas while keeping the toolbar in layout. Compare CSS zoom and transform: scale() for layout, overflow, event coordinates, and accessibility, then explain how you would debug nested zoom.
What the interviewer is testing
- Distinguishing layout-affecting zoom from a paint-only transform.
- Handling scroll containers, pointer coordinates, focus, browser zoom, and nested zoom.
- Validating the choice in real scenarios instead of selecting from a screenshot.
Questions to clarify first
- Is the target ordinary page content, an editable canvas, or a read-only preview?
- Must zoom change layout space, scroll range, and hit regions?
- Must it support keyboard navigation, screen readers, browser zoom, and high contrast?
A 30-second answer
If the zoom must change layout and scroll space, I would evaluate CSS zoom. If it is only a visual change and siblings must stay put, I would consider transform: scale() and handle transform origin, hit testing, and scrolling explicitly. zoom affects layout; scale() does not trigger layout recalculation. currentCSSZoom can expose the effective product of nested CSS zoom values, while browser zoom and transforms remain separate measurements.
Step-by-step deep dive
1. Define the zoom semantics
Page readability zoom should use browser and system controls rather than replacing user settings with CSS. A canvas editor needs an application scale and an explicit conversion between canvas and viewport coordinates; do not combine the two states.
2. Understand zoom’s layout effect
CSS zoom magnifies the target and affects page layout, so sibling positions, size calculations, and overflow range can change. It fits content that should occupy corresponding layout space, but minimum widths and scrollbar behavior need testing.
3. Understand transform: scale’s paint effect
transform: scale() changes painting and the transformed visual boundary without reflowing siblings. It fits previews or stable outer layouts, but transform-origin and conversions between visual and event coordinates must be explicit.
4. Keep the code boundary clear
.preview-zoom {
zoom: var(--preview-zoom, 1);
}
.canvas-visual {
transform: scale(var(--canvas-scale, 1));
transform-origin: top left;
}Do not accidentally stack both ratios on one component. Keep scale state near the canvas controller and decide separately whether the toolbar or canvas content inherits it; a root zoom should not unexpectedly resize navigation and dialogs.
5. Handle coordinates, focus, and scroll
Use getBoundingClientRect(), pointer coordinates, and scroll offsets to derive the transform, then verify in target browsers. Focus rings, drag handles, and keyboard navigation must remain visible; visual transform scaling does not automatically enlarge the container’s scroll area.
6. Debug nested zoom
Element.currentCSSZoom reports the effective product of CSS zoom on the element and its ancestors. It helps logs and debugging tools explain why content appears magnified several times. It is not a combined reading of browser page zoom or transform scale; record those separately.
7. Run accessibility and performance checks
Test browser zoom, system font preferences, keyboard operation, screen-reader order, high contrast, and reduced motion. Large or frequent zoom changes can increase layout and paint cost; throttle slider previews and save the precise value on release.
Model answer
I would first decide whether zoom must change layout space. If it must change scrolling and sibling positions, I would evaluate zoom; if the canvas should grow visually while the toolbar stays put, I would use transform: scale() and handle origin, scrolling, and pointer coordinates. Canvas state should not change browser page zoom or make dialogs inherit an accidental ratio. I would use currentCSSZoom to debug nested CSS zoom but record transforms and page zoom separately, then test keyboard focus, screen readers, scrolling, DPI, performance, and mobile devices.
Common mistakes
- Assuming
zoomandscale()only change visual size. - Expecting transform scaling to expand layout and scroll range automatically.
- Putting a canvas ratio on the root and scaling the toolbar, dialogs, and navigation.
- Ignoring pointer-coordinate conversion and focus visibility after scaling.
- Treating currentCSSZoom as a total including transforms or browser page zoom.
Follow-up questions and responses
When should you avoid CSS zoom?
Use browser and system controls for user readability. When the browser matrix or layout side effects are unacceptable, use normal layout, container queries, or an application coordinate transform.
What if the transformed visual boundary exceeds the container?
Define clipping and scrolling deliberately, measure the transformed boundary, and keep focus and drag handles visible. Do not hide the problem with overflow: hidden alone.
Why are pointer coordinates offset?
Event coordinates are usually viewport-relative, while canvas coordinates must subtract scroll and translation and divide by application scale. Put the conversion in one tested function and cover different transform origins.
How do you control nested zoom?
Limit the scope, centralize scale state, log each layer and currentCSSZoom, and prevent components from multiplying a ratio without knowing ancestor state.
How do you test browser page zoom?
At 100%, 125%, and 200%, check reflow, keyboard order, truncation, and horizontal scrolling. Keep page zoom and application canvas zoom as separate acceptance dimensions.
How do you quantify the choice in an interview?
Compare layout movement, scroll range, hit-test error, focus visibility, frame time, and input latency on target devices, then choose the property that matches the product semantics.