How would you debug a CSS layout that looks fine in Chrome but breaks in Safari?
Don’t guess, actually open Safari (or its engine, WebKit) and inspect it, since a huge share of “Safari bugs” are specific, well-known gaps rather than random inconsistency. Start by checking whether the layout uses flexbox or grid features Safari has historically lagged on: gap in flexbox (only reliably supported in newer Safari versions), min-height: 100% inside flex children not resolving the way Chrome resolves it, or position: sticky inside a container with overflow set, which Safari handles differently.
Systematic approach
Bisect the CSS: comment out sections of the stylesheet or isolate the broken component in a minimal test page until you find the exact property causing the divergence. Check Safari’s own web inspector (not just Chrome DevTools) since computed styles can differ between engines even when the source CSS is identical, revealing exactly where the engines disagree.
Best practice
Keep a mental (or literal) list of Safari’s known trouble spots and check them first before broad debugging: viewport units (vh) behaving differently on iOS Safari due to the dynamic toolbar, flexbox gap support cutoffs, backdrop-filter performance, and date input styling. Test on real Safari or a real iOS device when possible, since Safari’s desktop and mobile behavior can also diverge from each other.
Edge case interviewers probe for
Ask what you’d do if you don’t have access to a Mac to test Safari directly. Know that BrowserStack or similar cross-browser testing services, or cloud-based Safari testing tools, exist specifically for this, and that guessing without ever seeing the actual rendering is not an acceptable long-term strategy for a team shipping to Safari users.
Common mistake
Assuming any cross-browser inconsistency needs a vendor prefix, when most modern CSS properties don’t require them anymore, the actual cause is far more often a genuine behavioral difference in how the engine implements a spec, not a missing prefix.
What the interviewer is checking
Whether you debug cross-browser issues systematically with real testing on the actual engine, and whether you know Safari’s specific, documented quirks rather than treating “it’s just Safari being weird” as an explanation.
Think of CSS properties like a recipe written in English, and different browsers as chefs from different countries reading the same recipe. Most instructions (“preheat the oven to 350”) get followed identically everywhere. But some instructions (“a pinch of salt”) get interpreted slightly differently depending on the chef’s training, not because they’re being difficult, but because the instruction itself was always a little ambiguous or the chef’s kitchen (their engine) handles that specific step differently.
Safari isn’t randomly broken, it’s a chef with its own specific, well-documented habits: certain modern techniques (like the newest flexbox spacing tricks) arrived in its kitchen later than others, and some measurements (like “how tall is the visible screen” on a phone) get calculated slightly differently because of how its interface works. Knowing that chef’s specific habits ahead of time is faster than re-tasting the whole dish from scratch every time something looks off.
Why interviewers ask this
Cross-browser bugs are a daily reality in frontend work. This checks whether you debug them methodically or just start randomly changing CSS until it looks right.
What a strong answer signals
That you know Safari’s specific, documented quirks and test on the real engine rather than guessing from Chrome DevTools alone.
Common follow-ups
- How does iOS Safari’s dynamic toolbar affect viewport height units?
- What’s a CSS feature query and how would you use one here?
- How would you set up automated cross-browser visual regression testing?
Advanced variation
“How would you write CSS that gracefully degrades for a feature Safari doesn’t support yet,” which expects using @supports feature queries rather than browser-sniffing.
A checkout page’s sticky order-summary sidebar worked perfectly in Chrome but scrolled away entirely in Safari. The container had overflow: hidden set on a parent for an unrelated rounded-corner effect, which Safari interprets as breaking the containing block for position: sticky descendants more strictly than Chrome does. Removing the unnecessary overflow: hidden and achieving the rounded corners a different way (an inner wrapper instead of clipping the whole container) fixed the sticky behavior in both browsers.
/* Before: overflow:hidden on an ancestor silently breaks sticky in Safari */
.layout {
overflow: hidden; /* was only here for rounded corners */
}
.sidebar {
position: sticky;
top: 20px;
}
/* After: move the clipping to a dedicated inner wrapper instead */
.layout {
/* no overflow here anymore */
}
.layout-visual-clip {
overflow: hidden;
border-radius: 12px;
}
.sidebar {
position: sticky;
top: 20px;
}
/* Feature-detect instead of guessing when support is uncertain */
@supports (gap: 1px) {
.flex-row { gap: 16px; }
}- 1Test on the real Safari or WebKit engine rather than guessing from Chrome DevTools alone.
- 2Know Safari’s specific known quirks: sticky positioning under overflow, flexbox gap support, viewport units on iOS.
- 3Bisect the CSS to isolate the exact property causing the divergence rather than guessing broadly.
- 4Most modern cross-browser issues aren’t fixed by vendor prefixes; they’re genuine spec-implementation differences.
- 5Use @supports feature queries for graceful degradation instead of browser-sniffing.