Browser Support

Compatibility, Testing & Best Practices

Browsers are the gateways to your web experiences, yet they don’t all speak the same language. Behind the scenes, divergent rendering engines—Blink (Chrome, Edge), WebKit (Safari), Gecko (Firefox)—interpret HTML, CSS, and JavaScript differently. A flexbox layout that looks perfect in one browser might misalign in another; a modern API like fetch() might be unavailable in legacy environments. This fragmentation can lead to broken UIs, mysterious bugs, and frustrated users.

Rather than endless lists of “which browsers support CSS Grid,” this guide lays out a clear, strategic approach:

1. Fundamental Concepts: Understand rendering engines and progressive enhancement.
2. Feature Detection vs Sniffing: Use Modernizr and native checks, not brittle user‑agent parsing.
3. Compatibility Databases: Master “Can I use” for real‑time support stats.
4. Polyfills & Shims: Add missing features via libraries like core‑js or html5shiv.
5. Cross‑Browser Testing: Leverage BrowserStack, local installs, and manual checks.
6. CSS & Layout Patterns: Provide fallbacks for Grid, Flexbox, and custom properties.
7. HTML & JS API Support: Detect and polyfill <details>, IndexedDB, fetch(), and more.
8. Real‑World Scenarios: Gracefully fallback for Server‑Sent Events, Promises, and offline storage.
9. Automation Tools: Integrate Modernizr, MDN compatibility data, and Doiuse into your build.
10. FAQs & Best Practices: Answer common questions about dropping IE, balancing progress with compatibility, and automating reports.

By the end, you’ll have a repeatable workflow, armed with code examples and tool recommendations, to ensure your applications run reliably across the broad landscape of today’s—and tomorrow’s—browsers.

1. Fundamental Concepts

Rendering Engines & Their Impact

Browsers render pages using different engines:

• Blink: Google Chrome, Microsoft Edge (Chromium), Opera
• WebKit: Safari, older Chrome on iOS
• Gecko: Mozilla Firefox

Each engine has its own CSS parser, JavaScript runtime, and layout quirks. For example, flex gap support landed earlier in Blink than in WebKit, and certain CSS variables bugs persist in older Gecko versions.

Progressive Enhancement

Progressive enhancement means:

1. Baseline HTML: Ensure core content and functionality work in all browsers—use semantic tags (<a>, <button>, form controls).
2. CSS Layer: Add modern layouts (Flexbox, Grid) inside @supports or via feature queries, while providing simpler float or inline‑block fallbacks.
3. JavaScript Layer: Feature‑detect APIs (e.g., if ('fetch' in window) { … } else { /* polyfill or fallback */ }) rather than blocking on unsupported features.

This ensures users on older browsers see a functional experience, while modern browsers get richer interactions.

2. Feature Detection vs Browser Sniffing

Why Feature Detection Wins

Browser sniffing (parsing navigator.userAgent) is brittle: strings change, devices spoof, and you’ll miss edge cases. Instead, test directly:

if ('canvas' in document.createElement('canvas')) {
  // Use canvas API
} else {
  // Fallback image or Flash (legacy)
}

if ('canvas' in document.createElement('canvas')) {
  // Use canvas API
} else {
  // Fallback image or Flash (legacy)
}

Modernizr Example

Modernizr generates CSS classes and JS flags based on feature tests:

<script src="modernizr.js"></script>
<script>
  if (Modernizr.fetch) {
    fetch('/data.json').then(/*…*/);
  } else {
    // Load fetch polyfill or use XMLHttpRequest
    var script = document.createElement('script');
    script.src = 'https://cdn.jsdelivr.net/npm/whatwg-fetch';
    document.head.appendChild(script);
  }
</script>

<script src="modernizr.js"></script>
<script>
  if (Modernizr.fetch) {
    fetch('/data.json').then(/*…*/);
  } else {
    // Load fetch polyfill or use XMLHttpRequest
    var script = document.createElement('script');
    script.src = 'https://cdn.jsdelivr.net/npm/whatwg-fetch';
    document.head.appendChild(script);
  }
</script>

Benefits

• Tests actual support, not assumptions.
• Enables branching: load polyfills conditionally.
• Adds CSS classes (.no-flexbox, .flexbox-gap) to apply visual fallbacks.

Feature detection is the cornerstone of robust compatibility strategies.

3. Using Compatibility Databases

“Can I use” as the Source of Truth

Can I use tracks HTML5, CSS3, and JS API support across browsers, with global usage percentages.

• ✅ Supported
• ◐ Partial (prefix or limitation)
• ❌ Unsupported

Interpreting the Tables

• Stable Support: Look for green ✅ in all target browsers.
• Partial: Shades of green/orange; check notes for prefixes or bugs.
• Global Usage: Prioritize features with >90% usage in your audience’s browsers.

Example: EventSource (Server‑Sent Events)

if ('EventSource' in window) {
  var es = new EventSource('/sse');
  es.onmessage = function(e) {
    console.log('SSE:', e.data);
  };
} else {
  // Fallback to WebSocket or long‑polling
  pollServer();
}

if ('EventSource' in window) {
  var es = new EventSource('/sse');
  es.onmessage = function(e) {
    console.log('SSE:', e.data);
  };
} else {
  // Fallback to WebSocket or long‑polling
  pollServer();
}

On Can I use, “EventSource” shows:

• ✅ Chrome, Firefox, Safari (latest)
• ❌ IE, certain mobile browsers

Global support ~86%—ask: is SSE critical? If yes, bundle a polyfill or use fallback.

Example: dataset (data-* attributes)

HTML5 data-* support is universal in evergreen browsers. Can I use marks:

• ✅ All modern browsers
• ❌ Very old IE8 (use getAttribute('data-foo') fallback)

By consulting compatibility tables early, you decide which features require polyfills, shims, or design adjustments—saving debugging time later.

4. Polyfills, Shims & Progressive Enhancement

Defining Terms

• Polyfill: Code that implements a missing standard API (e.g., Promise, fetch, Array.prototype.includes).
• Shim: Lightweight wrapper to normalize behavior (e.g., a function alias).

HTML Polyfills

• html5shiv: Enables styling of HTML5 elements in IE8 by creating them via JS.
• details/polyfill: Adds <details> support in older browsers.

JavaScript Polyfills

Use core‑js with Babel:

npm install core-js

npm install core-js

import 'core-js/stable';
import 'regenerator-runtime/runtime';

import 'core-js/stable';
import 'regenerator-runtime/runtime';

This bundles only needed polyfills based on .browserslistrc targets.

CSS Feature Queries

@supports (display: grid) {
  .container { display: grid; grid-template-columns: 1fr 1fr; }
}
@supports not (display: grid) {
  .container { display: block; }
  .container > * { float: left; width: 50%; }
}

@supports (display: grid) {
  .container { display: grid; grid-template-columns: 1fr 1fr; }
}
@supports not (display: grid) {
  .container { display: block; }
  .container > * { float: left; width: 50%; }
}

@supports lets you write modern CSS with graceful fallbacks—no extra classes or JS needed.

5. Testing Across Browsers

Local & Cloud Testing Tools

• Local installs: Have Chrome, Firefox, Edge, and Safari on macOS; use VirtualBox for older IE versions.
• BrowserStack / Sauce Labs: Cloud platforms offering real device/browser combinations.
• Lighthouse and axe: Automated accessibility audits in Chrome DevTools.

Workflow Integration

1. “Can I use” Lookup: Before using a feature, check support.
2. Manual Verification: After implementation, open on each target browser and test critical flows.
3. Automated E2E Tests: Use Selenium, Cypress, or Playwright on multiple browsers via CI.
4. Visual Diffing: Tools like Percy or BackstopJS catch layout regressions.

Critical Feature Checks

• Layout (Grid/Flex)
• Form controls (date pickers, range inputs)
• Media playback (<video>, <audio>)
• JS APIs (fetch, Promise, Intl)

Regular compatibility checks prevent surprises at release time.

6. CSS & Layout Support

Foundational CSS

• Box model, float, inline‑block, position: Universally supported.
• Media queries (@media): Works in all modern browsers and IE9+.

Modern Layouts

• Flexbox: Broad support in evergreen browsers; some IE11 bugs (e.g., min-height on flex items).
• CSS Grid: Supported in Chrome 57+, Firefox 52+, Safari 10.1+; use @supports(display: grid) for fallback.
• Custom Properties (--var): Supported in evergreen; for older, use Sass/Less variables.

@supports (display: grid) {
  .card-container { display: grid; grid-template-columns: repeat(3, 1fr); gap: 1rem; }
}
@supports not (display: grid) {
  .card-container { display: flex; flex-wrap: wrap; }
  .card-container > * { flex: 1 1 calc(33.333% - 1rem); }
}

@supports (display: grid) {
  .card-container { display: grid; grid-template-columns: repeat(3, 1fr); gap: 1rem; }
}
@supports not (display: grid) {
  .card-container { display: flex; flex-wrap: wrap; }
  .card-container > * { flex: 1 1 calc(33.333% - 1rem); }
}

Fallback Patterns

• Float + Inline‑Block: Classic two‑column layouts.
• object-fit: cover fallback via JS or background images for images not fitting their container.
• Viewport units (vh, vw): Good support, but mobile browser UI can affect heights—test carefully.

7. HTML & JavaScript API Compatibility

HTML5 Elements

• <details>, <summary>, <dialog>: Check support; polyfill if needed.
• Media capture (<input type="file" accept="image/*" capture>): Mobile support varies; provide file picker fallback.

Storage APIs

• localStorage/sessionStorage: IE8+, evergreen; wrap in try/catch for disabled cookies.
• IndexedDB: Supported in modern browsers; fallback to localStorage or WebSQL (deprecated).
• Cache API & Service Workers: Supported in Chrome, Firefox, Edge; no Safari service worker support before v11.1—detect and degrade to network‑only.

JS APIs

• fetch: Polyfill via whatwg-fetch.
• Promises: Polyfill via core-js or es6-promise.
• Intl (internationalization): Partial support in Safari—use polyfills for locale data.
• WebSockets: Widely supported; fallback to SockJS or long‑polling.

Feature‑detect before use:

if (typeof fetch === 'function') {
  // modern fetch
} else {
  // load polyfill or fallback to XHR
}

if (typeof fetch === 'function') {
  // modern fetch
} else {
  // load polyfill or fallback to XHR
}

8. Real‑World Compatibility Scenarios

8.1 Server‑Sent Events (SSE) vs Polling

if ('EventSource' in window) {
  const es = new EventSource('/sse');
  es.onmessage = e => updateUI(e.data);
} else {
  // Fallback to polling
  setInterval(() => fetch('/updates').then(r => r.json()).then(updateUI), 5000);
}

if ('EventSource' in window) {
  const es = new EventSource('/sse');
  es.onmessage = e => updateUI(e.data);
} else {
  // Fallback to polling
  setInterval(() => fetch('/updates').then(r => r.json()).then(updateUI), 5000);
}

• SSE: Simple, one‑way streaming.
• Polling: Universal fallback with latency trade‑off.

8.2 IndexedDB, Promises & Fetch

if (window.indexedDB) {
  // use IndexedDB for caching
} else {
  // fallback to localStorage
}

if (window.indexedDB) {
  // use IndexedDB for caching
} else {
  // fallback to localStorage
}

Chain detection:

if ('Promise' in window && 'fetch' in window) {
  fetch('/data').then(r => r.json()).then(cacheData);
} else {
  // Load polyfills or use XHR + callbacks
}

if ('Promise' in window && 'fetch' in window) {
  fetch('/data').then(r => r.json()).then(cacheData);
} else {
  // Load polyfills or use XHR + callbacks
}

8.3 Offline‑First UX

Use Service Workers when available; fallback to uncached network:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}
// Always design so network failure still shows core content.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}
// Always design so network failure still shows core content.

8.4 CSS Grid in Article Layout

@supports (display: grid) {
  .articles { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); gap: 1rem; }
}
@supports not (display: grid) {
  .articles li { float: left; width: 200px; margin: 0.5rem; }
}

@supports (display: grid) {
  .articles { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); gap: 1rem; }
}
@supports not (display: grid) {
  .articles li { float: left; width: 200px; margin: 0.5rem; }
}

Graceful degradation: floats replicate grid columns.

9. Tools & Automation

Modernizr

• Auto‑generates JS flags and CSS classes (.no-flexbox, .promises) based on feature tests.
• Use build tools to include only necessary tests.

MDN Browser Compatibility Data

• JSON data that powers MDN docs; can integrate in scripts to warn about unsupported APIs at build time.

Doiuse

• A PostCSS plugin that lints CSS against Can I use data, flagging unsupported properties.

npm install --save-dev doiuse

npm install --save-dev doiuse

postcss([ require('doiuse')({ browsers: ['>1%', 'last 2 versions', 'not ie <= 11'] }) ])

postcss([ require('doiuse')({ browsers: ['>1%', 'last 2 versions', 'not ie <= 11'] }) ])

BrowserStack & Puppeteer

• Automate cross‑browser tests using Puppeteer scripts on BrowserStack’s infrastructure.
• Integrate compatibility checks into CI (GitHub Actions) to fail builds on regressions.

Automation saves time and ensures no critical feature slips through.

10. FAQs

Q1. Should I drop support for IE?
Microsoft has ended IE support; focus on evergreen browsers and provide minimal fallbacks for enterprise users. Use analytics to guide decisions.

Q2. How do I maintain compatibility without holding back innovation?
Adopt progressive enhancement: ship core functionality first, then layer on modern features with feature detection and polyfills only where needed.

Q3. How to test complex features easily?
Combine feature detection, automated E2E tests (Cypress/Puppeteer), and visual diff tools (Percy) to catch layout and functional regressions.

Q4. Can we automate compatibility reports?
Yes. Use tools like MDN’s BCD, Doiuse, and CI pipelines to generate HTML/CSS/JS compatibility summaries as part of your build.

11. Conclusion

Ensuring broad browser compatibility in 2025 requires a strategic blend of feature detection, progressive enhancement, and automated tooling. By understanding rendering engine differences and leveraging “Can I use” and Modernizr data, you can make informed decisions about which modern APIs to adopt and where to apply graceful fallbacks. Implement polyfills and shims for critical features, and test continuously across real browsers via BrowserStack or local setups. Employ CSS feature queries and JS detection to load only what’s necessary, preserving performance and user experience. Finally, integrate compatibility checks into your CI/CD pipeline with tools like Doiuse and MDN browser‑compat data. With these practices, you’ll build resilient, future‑ready web applications that delight users on every device and browser—past, present, and future.

About The Author

Pavan Kalyan

See author's posts