CSS Browser Compatibility: Fixes & Hacks

Cross-browser CSS is in the best shape it’s ever been — and it still bites. Internet Explorer is gone, the major engines coordinate on interoperability, and most of the properties you use daily work everywhere. The bugs that remain are subtler: a layout that’s fine in Chrome but off by a scrollbar-width in Firefox, a 100vh hero that jumps around in mobile Safari, a shiny new property that silently does nothing for a fifth of your visitors.

This guide covers the strategy (deciding what to support), the techniques (resets, fallbacks, feature queries), and the workflow (how to actually find and fix the differences). Disclosure: examples in the debugging section use Hoverify, which is our product; everything else here is tool-agnostic.

Why browsers render CSS differently

Three rendering engines power effectively every browser:

Engine	Used by	Notes
Blink	Chrome, Edge, Opera, Brave, Arc	Dominant share; usually first to ship new CSS
WebKit	Safari — and every browser on iOS	Apple’s engine; iOS Chrome and Firefox are WebKit too
Gecko	Firefox	Independent implementation; catches spec ambiguities the others miss

Two practical consequences:

1. Testing “Chrome and Firefox on your laptop” misses the biggest source of surprises. On iOS, every browser is WebKit under the hood, so Safari quirks affect all iPhone users no matter which browser icon they tap.
2. New features land in different engines at different times. A property that’s shipped in Blink may be months (or years) from the others. Check caniuse.com before relying on anything recent, and look for the Baseline badge — “Baseline Widely available” means a feature has been supported in all major engines long enough to use without fallbacks.

The good news: since 2022 the engine vendors have run the annual Interop project together, systematically fixing cross-engine differences. The list of genuinely broken things shrinks every year. What’s left is mostly timing differences on new features — which is a problem you can engineer around.

First, decide what you actually support

Most compatibility effort is wasted on browsers nobody uses on your site. Before writing a single hack:

• Check your analytics. Your real browser mix is the only support matrix that matters. A B2B dashboard for corporate clients and a consumer mobile site have completely different tails.
• Write the matrix down. “Last 2 versions of Chrome, Firefox, Safari, and Edge, plus Safari on iOS 16+” is a policy your team can test against. “It should work everywhere” is not.
• Let the tail go. Internet Explorer was retired by Microsoft in June 2022; unless you serve a locked-down enterprise environment that still pins it, IE hacks are dead code. Shopify dropped IE11 from new themes back in 2020 after finding it produced a tiny fraction of checkouts — measure, decide, and delete.

Supporting an old browser isn’t free: fallback code and polyfills increase bundle size for everyone, which slows the modern majority down to serve the legacy minority. That trade should be a decision, not a default.

The baseline: resets and normalization

Every browser ships default styles, and they differ — margins, font sizes, form control appearance. Start from a consistent base:

• A modern reset zeroes out the defaults you’d otherwise fight. Josh Comeau’s custom reset is a good current choice:

*, *::before, *::after { box-sizing: border-box; }
* { margin: 0; }
body { line-height: 1.5; -webkit-font-smoothing: antialiased; }
img, picture, video, canvas, svg { display: block; max-width: 100%; }
input, button, textarea, select { font: inherit; }
p, h1, h2, h3, h4, h5, h6 { overflow-wrap: break-word; }

• The single highest-value line in any reset is box-sizing: border-box — it makes width calculations mean the same thing in every browser and every element.
• Normalize.css-style normalization is the gentler alternative: it keeps useful defaults and only fixes the inconsistencies. Either approach works; the point is to choose one and stop inheriting browser disagreements.

Form controls deserve a special mention: they’re the least consistent elements on the web. If you’re styling buttons, selects, or inputs heavily, appearance: none (with the -webkit- prefix for older WebKit) resets them to a stylable blank slate.

Fallbacks: CSS’s built-in compatibility mechanism

CSS was designed for this problem. Browsers ignore declarations they don’t understand, which gives you a zero-JavaScript fallback pattern — declare the safe value first, the modern value second:

.overlay {
    background: rgb(0 0 0 / 0.4);
    background: color-mix(in oklch, var(--brand), transparent 60%);
}

Every browser applies the first line; browsers that understand color-mix() override it with the second. The same layering works for custom properties:

.button {
    background-color: #007bff;              /* fallback */
    background-color: var(--primary, #007bff);
}

For anything structural, use feature queries — @supports is the CSS-native way to branch on capability rather than browser:

.container {
    display: flex;       /* works everywhere */
    flex-wrap: wrap;
}

@supports (display: grid) {
    .container {
        display: grid;
        grid-template-columns: repeat(3, 1fr);
    }
}

This is progressive enhancement in one snippet: a working layout for every browser, a better one where the capability exists. The question is never “which browser is this?” — it’s “can this browser do what I’m about to ask?”

On vendor prefixes: they’re mostly a solved problem. Don’t hand-write -webkit-/-moz- variants; add Autoprefixer to your build (or use a framework that includes it) and let real browser-support data decide which prefixes your target matrix still needs. Hand-written prefixes go stale; generated ones get pruned automatically as browsers move on.

For JavaScript-side gaps, the equivalent tools are polyfills (code that implements a missing API) and transpilers like Babel that compile modern syntax down to what your support matrix understands. Use them deliberately — every polyfill is bundle weight the modern majority pays for.

The compatibility trouble spots that still exist

With IE gone, these are the differences that actually cost debugging hours today:

• Mobile Safari’s dynamic viewport. The collapsing URL bar means 100vh is taller than the visible screen while the bar is shown. Use 100dvh (dynamic viewport height) with a 100vh fallback declared above it.
• Scrollbars affect layout differently. Overlay scrollbars (macOS, mobile) take no space; classic scrollbars (Windows) do. A layout that’s flush in your macOS Chrome can overflow on a Windows machine. scrollbar-gutter: stable helps.
• Form controls and accent-color. Native widgets still render differently per platform. Decide early whether you’re accepting native appearance or fully restyling — half-measures look broken somewhere.
• Font rendering. Windows (DirectWrite) and macOS (Quartz) rasterize differently; the same font at the same size has different metrics and weight. Don’t pixel-match typography across OSes — verify line-wrapping and overflow instead.
• Flexbox minimum sizing. min-width: auto on flex children causes overflow bugs that surface differently per engine; min-width: 0 on the squeezed child is the classic fix.
• New-feature timing. Subgrid, :has(), container queries, scroll-driven animations — all landed in different engines in different years. Anything shipped in the last ~two years deserves a caniuse check and a fallback plan.

A cross-browser debugging workflow

When something looks wrong “only in browser X,” a systematic loop beats guessing. This is the five-step process we use:

1. Reproduce it precisely. Same page, same viewport width, same content, side by side in the affected and unaffected browsers. Half of “browser bugs” turn out to be different viewport sizes or cached CSS — clear cache and cookies first (Hoverify’s Debug tool does this in one click, or use DevTools’ hard reload).

2. Isolate the element. Inspect the broken element in both browsers and compare computed styles, not authored styles. The declaration that differs — or applies in one browser and not the other — is your suspect. Hoverify’s Inspector makes this loop fast: hover any element to see its CSS, media queries, and pseudo-element styles without opening DevTools, and edit values live to test a fix in place.

3. Check the suspect on caniuse. If the differing property is new or partially supported, you’ve found your cause, and the fix is a fallback or feature query from the section above.

4. Apply the fix and re-verify everywhere. A fix for Safari can regress Chrome. Re-check every browser and breakpoint in your support matrix — this is where multi-device tooling pays off, since Hoverify’s Responsive tool renders multiple viewports side by side with synced scrolling and clicks. There’s a fuller walkthrough in our responsive debugging guide.

5. Document why the code exists. A one-line comment (/* 100dvh fallback: Safari < 15.4 */) stops the next developer from “cleaning up” a load-bearing hack — and tells you when it’s safe to delete.

If the bug is a layout problem rather than a support gap, our systematic CSS debugging guide goes deeper on isolating layout issues specifically.

Testing: catch it before users do

• Local baseline: keep Chrome and Firefox installed; that covers Blink and Gecko. If you’re not on a Mac, Safari is the engine you’re blind to — and statistically the one most likely to differ.
• Real WebKit: test iOS Safari on actual hardware when you can; simulators miss the URL-bar viewport behavior and touch quirks.
• Cloud browsers: BrowserStack and LambdaTest cover the combinations you don’t own — old Safari versions, Windows font rendering, Android browsers — on demand.
• Automate the boring part: viewport screenshots of key pages, diffed per browser on deploy, catch visual regressions for free. Our complete responsive testing guide covers building that testing ladder in detail.

Don’t chase pixel-identical rendering — fonts alone make that impossible. The standard worth holding is: same content, working functionality, no broken layouts, in every browser on your matrix.

The short version

1. Define a support matrix from your analytics, and delete code for browsers below it.
2. Start from a reset, with box-sizing: border-box non-negotiable.
3. Layer declarations safe-first and branch with @supports — capability checks, never browser sniffing.
4. Let Autoprefixer and Babel handle prefixes and syntax; keep polyfills deliberate.
5. Debug by comparing computed styles, verify fixes on every engine, and comment the weird code.

Compatibility work rewards boring discipline more than clever hacks. The hacks in this post’s title mostly belong to the IE era — what replaced them is a workflow, and once it’s cheap to run, you stop fearing the “looks broken in Safari” bug report. That loop — inspect, edit live, re-check every viewport in one window — is exactly what Hoverify was built to make fast.