HTML Browser Support

Introduction

HTML feature browser support matrices drive progressive enhancement and CI browser targets — not "caniuse green check" trivia. Staff engineers map features (popover, inert, dialog, input type=date) to baseline support tiers, fallback HTML, and polyfill budget with measurable user impact from analytics.

Business problem

Business pressure: Shipping dialog without fallback traps focus on Safari 15; assuming input type=date works everywhere breaks checkout on older embedded WebViews — support matrices prevent revenue loss.

• Contracts: Enterprise SLAs name browser versions — HTML features must align.
• Analytics: 3% traffic on unsupported feature needs graceful degradation path.
• Maintenance: Polyfill sprawl without matrix documentation — remove polyfill breaks silent minority.

Why this feature exists

Platform motivation: Living HTML standard ships unevenly across engines — Chromium, WebKit, Gecko differ on new elements and attributes.

• History: caniuse and BCD (Browser Compatibility Data) centralized knowledge; MDN uses BCD badges.
• Alternative rejected: Lowest common denominator only — misses native a11y wins.
• Modern role: @supports and baseline.w3c.org inform enhancement layers.

Browser internals

Unsupported tags/attrs: Unknown elements become HTMLUnknownElement — often still styled; unknown input types fall back to text — behavior must be tested not assumed.

• Parser: All major engines HTML5 parse consistently; feature gaps are post-parse APIs and UI widgets.
• DOM: dialog.showModal() missing — need role=dialog polyfill pattern.
• Script impact: type=module unsupported — nomodule fallback script pattern legacy.

Rendering workflow

Support-driven rendering: picture/source for WebP with JPEG fallback; font-display swap for older FOIT behavior; loading attr ignored in old browsers — still ok, progressive.

• Critical path: Feature detect preload vs prefetch support rare — mostly universal.
• Layout: subgrid/flex gap CSS often paired — HTML structure independent.
• Paint: video autoplay policies vary by browser — attribute alone insufficient.

Feature deep dive

Support tier model: Tier 1 (full features), Tier 2 (graceful degrade), Tier 3 (best effort). Map HTML features: dialog, details/summary, ruby, datalist, input types, popover, inert, lazy loading.

• Detection: @supports, typeof HTMLDialogElement, feature tests in boot script.
• Fallback HTML: Native select instead of datalist; link instead of popover menu when needed.
• WebView: Embedded apps in LinkedIn/Instagram — separate matrix row.

if (typeof HTMLDialogElement === "function") {
  document.querySelector("dialog").showModal();
} else {
  // fallback: expose content inline with details open
}

Accessibility analysis

A11y + support: Native dialog and inert improve a11y when supported; polyfill fallbacks must preserve focus management and roles.

• Screen readers: Test SR + browser pairs — NVDA+Firefox vs VoiceOver+Safari.
• Keyboard: Polyfill dialog must trap Esc and Tab.
• WCAG: Baseline accessibility required on Tier 3 — not "unsupported browser no a11y."

SEO impact

SEO crawlers: Googlebot runs evergreen Chromium — different matrix than corporate IE legacy. SEO HTML can use modern features crawlers support while Tier 2 users degrade.

• Crawl: lazy loading respected by Googlebot with nuance — LCP image still eager.
• Rich results: JSON-LD independent of user browser matrix.
• Core Web Vitals: CrUX segmented by device — mobile WebView support matters for field data.

Security considerations

Old browsers: Legacy engines lack modern CSP features and sandbox attrs — defense in depth on server; don't rely solely on sandbox in IE.

• XSS: Polyfills may introduce script — SRI and CSP on polyfill CDN.
• CSP: strict-dynamic not in old browsers — plan hashes/nonces carefully.
• Clickjacking: X-Frame-Options fallback where CSP unsupported.

Performance impact

Polyfill cost: Each polyfill hits INP and bundle — traffic-weight whether 0.5% users justify 20KB.

• LCP: Modern img attrs safe as progressive enhancement.
• INP: Feature detect once at boot, not per interaction.
• CLS: Fallback layout must reserve same space as modern path.

Real production example

Support matrix in repo: browserslist config + documented HTML feature table linked from ADR; Playwright tests on Tier 1 matrix weekly.

# .browserslist
> 0.5%
last 2 versions
not dead
not op_mini all

Enterprise usage

Enterprise: Customer-facing app publishes "Supported environments" referencing HTML feature tiers; internal tools may be Chromium-only — document divergence.

• Design system: Components list baseline and fallback markup variants.
• CMS: Disable features unsupported in author browser tier? No — server renders fallback.
• CI gates: Playwright cross-browser on critical HTML flows.

Common production failures

What breaks in prod: input type=date on corporate SSO portal still IE mode — empty field blocked payroll submission.

• Incident: dialog shipped without fallback — keyboard trap in legacy Safari.
• SEO regression: N/A often — crawler modern; real users hurt separately.
• Perf regression: Polyfill bundle loaded for all users though 99% native support.

Architecture review questions

• Is there documented fallback HTML for each modern feature used?
• Does analytics traffic justify polyfill cost?
• Are crawlers and users on different support tiers accounted for?
• Do accessibility fallbacks meet WCAG on Tier 2 browsers?
• Is browserslist aligned with customer contracts?

Hands-on project

Project: Build HTML feature support table for 10 features with fallback markup samples and @supports detection snippet.

• Deliverable: reference page + feature detect module.
• Verify: Test in Playwright chromium/webkit/firefox.
• Stretch: Weight decisions with mock analytics CSV.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

HTML browser support reference powers progressive enhancement — tiered fallbacks, feature detection, analytics-weighted polyfill decisions, and cross-browser a11y testing beyond caniuse checkmarks.