98% isn't much

Original Article ↗ Hacker News Discussion ↗

Treating “98% coverage” as “good enough” can be dangerously misleading, especially when the remaining 2% represents millions of users or high‑stakes failures. Commenters contrast web development choices—like adopting new CSS features that break on older browsers—with domains such as safety‑critical systems, payments, accessibility, and public services, where even small failure rates are unacceptable. The central theme is that percentages only make sense in context: you must weigh the cost of supporting edge cases against the business, ethical, and reputational impact of excluding them, and use progressive enhancement or graceful degradation where possible.

Context: “98%” Is Highly Domain‑Dependent

  • Many argue the key variable is cost of failure, not the raw percentage.
  • 98% can be excellent for “upside” metrics (market share, conversion lift), but unacceptable for “downside”/safety (planes, surgery, food safety, car AIs, uptime/SLA).
  • Repeated events compound: 1–2% failure per query, pane, or session means almost every user soon hits a bad case.

Browser Support, Old Devices, and Business Impact

  • Big debate over dropping support for old browsers (IE, ancient mobile, locked‑down corporate machines).
  • One camp: build for the 95–98% using modern, evergreen browsers; legacy support is costly, slows development, and users should upgrade.
  • Other camp: small percentages can represent high‑value office workers, B2B customers, or millions of government users; losing 2–6% of such traffic can be financially huge.
  • Some note real traffic still comes from IE9/11 and old Android, often during office hours. Others say very old UAs are mostly bots or edge cases not worth targeting.

Progressive Enhancement vs. All‑or‑Nothing Features

  • Many emphasize graceful degradation: use new CSS/JS for “nice to have” features, but keep core functionality working everywhere.
  • Examples: fallback images instead of AVIF/WebP‑only; simpler layouts when nesting or flexbox aren’t supported; feature detection via @supports/JS.
  • Counterpoint: some features (e.g., replacing Sass with native CSS nesting) are structurally all‑or‑nothing, making progressive enhancement hard.

Accessibility, Equity, and Ethics

  • Some see dropping old browsers as class discrimination or analogous to excluding people with disabilities; argue inclusivity is “the right thing,” especially for public services.
  • Others claim businesses can legitimately decide not to serve low‑value or extremely costly segments, just as luxury brands ignore budget shoppers.
  • Wheelchair access and digital access for essential services are cited as areas where regulation or public‑good logic should override pure profit.

Measurement, Statistics, and Perception

  • Several note that global browser stats (e.g., caniuse, analytics) may undercount privacy‑focused users and Firefox, and overcount stale Chrome UAs.
  • People recommend reframing 98% as “1 in 50 fails” or using odds/log‑odds; small changes near 100% can halve failure rates.
  • Thread repeatedly stresses that many overlapping 98% decisions can cumulatively exclude far more than 2% of users.

Skepticism of the Article’s Framing

  • Some think the article mixes unlike domains (CSS vs food poisoning) and ignores cost–benefit.
  • Others respond that its core message is modest: don’t be lulled by “98% supported” claims; check who your actual users are, what’s at stake, and whether you can degrade gracefully.