Detailed explanation
Cross-browser CSS compatibility issues occur when browsers interpret styles differently, implement different specification versions, or lack support for a feature. Common examples include inconsistent default margins and form-control styles, older flexbox bugs, missing flexbox gap support, and differences in fonts or intrinsic sizing. The goal is not necessarily pixel-identical rendering everywhere: essential content and interactions must remain usable across the project's supported browsers and devices.
Start by separating browser defaults from actual implementation differences. Most elements use content-box by default, but user-agent styles can give certain controls different box-sizing behaviour. A common baseline is `*, *::before, *::after { box-sizing: border-box; }`, combined with a reset or normalize stylesheet. Normalize targets inconsistent defaults while preserving useful browser styling; resets generally remove more defaults. Native inputs, selects, and buttons can still vary by browser and operating system. If using `appearance: none`, explicitly restore necessary visual affordances and visible keyboard-focus styles.
Layout differences need targeted diagnosis. Older Safari versions have flexbox sizing and shrinking quirks, while older browsers may support flexbox without supporting gap in flex layouts. Inspect computed styles and reduce failures to a minimal example before changing the layout. An explicit flex-basis or `min-width: 0` may address a specific sizing problem, but these are not universal fixes. Use margins as a spacing fallback when necessary. Feature queries enable progressive enhancement: define a usable flex or block layout first, then apply grid inside `@supports (display: grid)`. Importantly, `@supports (gap: 1rem)` cannot reliably distinguish older browsers that support gap in grid but not flexbox.
Check compatibility tables such as Can I Use against an agreed browser-support matrix. Configure Autoprefixer through Browserslist to generate required vendor prefixes during the build; prefixes cannot implement unsupported features or repair every browser bug. Test representative pages in Chromium, Firefox, and Safari, including relevant mobile devices, with browser developer tools and real-browser testing services when available. Interviewers value this evidence-based workflow: identify the failing environment, isolate the cause, choose a maintainable fallback, and verify accessibility and functionality.
Key points to remember
- Establish supported browser versions before choosing CSS features and fallbacks.
- Use a reset or normalize stylesheet and an explicit box-sizing baseline.
- Investigate flexbox sizing, flex gap support, and native form-control differences.
- Use progressive enhancement and @supports, recognising that support checks do not detect every layout bug.
- Configure Autoprefixer with Browserslist and verify behaviour across browser engines.
Common mistakes candidates make
- Assuming vendor prefixes make every modern CSS feature work in older browsers.
- Using @supports (gap: 1rem) as definitive proof of flexbox gap support.
- Testing only in Chrome or applying browser-specific hacks before isolating the cause.
Likely follow-up questions
What is the difference between a CSS reset and Normalize.css?
A reset removes many default styles so you can define your own baseline. Normalize.css preserves useful defaults while correcting selected inconsistencies; neither adds support for missing layout features.
How would you provide a fallback for CSS Grid?
Declare a usable block or flex layout outside any feature query, then enhance it inside `@supports (display: grid)`. Browsers without feature-query support still receive the baseline styles, so an explicit negative query is usually unnecessary.
How would you handle missing flexbox gap support?
For a simple row or column, use margins between items as a compatible spacing strategy. Wrapping layouts need more careful margin handling; if you switch between margins and gap, use a reliable layout-based detection mechanism and avoid applying both spacing methods together.
Interview tip: Structure your answer around concrete incompatibilities, explain one fallback, and finish with how you test the supported browsers.