LSCSS

Guide

Browser Support Strategy

Supporting every browser forever is not a strategy. It is a slow, expensive argument wearing a project plan.

Good browser support decisions come from user needs, business risk, and progressive enhancement, not fear of one ancient laptop in a meeting room somewhere.

Common mistakes

  • supporting browsers nobody actually uses
  • building for browser versions instead of features
  • treating perfect visual parity as a requirement
  • shipping large polyfills for tiny edge cases
  • blocking modern improvements because of old assumptions
  • having no written support policy at all

Better rules

  • define a clear support matrix
  • use browserslist where tooling supports it
  • prefer feature support over version support—for CSS, JS, and APIs
  • progressively enhance instead of forcing equality
  • test critical journeys, not every pixel everywhere

How LSCSS helps

Layered CSS architecture makes progressive enhancement easier. Modern features like @scope, nesting, logical properties, and container queries fit cleanly when older browsers still receive a stable baseline experience.

Start here

Capture the policy in writing—start from thesupport matrix template(feature baseline, version list, or both)—then wirebrowserslist and build targetsso Autoprefixer, transpilers, and your CSS agree on the same surface. Revisit the matrix when analytics or contracts change—not only at kickoff.

Recommended reading

Browser support should be a clear policy, not an implicit set of assumptions people rediscover each sprint.