Why 98% Support Is Not Enough for Robust Engineering

98% Success Rates Mask Critical Gaps

A 98% success rate sounds high, yet in contexts where failure has serious consequences—food safety, payroll, or accessibility—it translates to frequent, unacceptable incidents. For a restaurant, 98% food‑poisoning‑free service means a customer gets sick roughly once a month. For an employer, missing a paycheck 2% of the time is a major breach of trust.

Percentages Mislead When Stakes Are High

When the cost of failure is high, the absolute number of failures matters more than the percentage. A website that works for 98% of the global population still excludes about 150 million users. If those users belong to a specific target audience, the impact can be even larger. The author’s own experience with nested CSS illustrates this: although the feature is “widely supported” in generic statistics, only ~70% of the site’s visitors could use it, leaving 30% of the audience stranded.

Edge Cases Require Graceful Degradation

Robust engineering is not about “most users get it right”; it is about handling the edge cases gracefully. If a new browser feature cannot degrade, the 2% who lack support experience a broken experience, which contradicts the claim of “wide support.” Progressive enhancement—checking feature support with @supports or JavaScript feature detection—allows developers to provide a functional baseline for all users while offering advanced features where possible.

Community Perspectives on the 98% Threshold

wccrawford: "If your business plan requires you to capitalize on more than 98% of the market, it’s already a failure. The trade‑off is code complexity vs. market size, and each company must decide individually."

nemo1618: "Removing >99% of needles from a Christmas tree still leaves a visible mess; the remaining 1% stands out more as you approach 100%."

MatekCopatek: "Profit motives often drive the acceptance of 98% support. Ticketing services, for example, may ignore a 2% failure rate because fixing it would cost more than the lost sales."

phailhaus: "Percentages can be deceptive; expressing success as odds (1 in 50 vs. 1 in 100) highlights the real impact of moving from 98% to 99%."

onion2k: "If a feature can’t degrade gracefully, it isn’t truly ‘widely supported.’ Use progressive enhancement with @supports or feature‑detecting JavaScript; the extra work is minimal."

collinmanderson: "US and UK government websites officially support only 98% of browsers. With 1.66 billion sessions in a month, 2% equals roughly 33 million sessions—far from negligible."

compiler‑guy: "Early OCR software boasted 99% accuracy, but that still meant five errors per page—demonstrating that high percentages can still produce noticeable failures."

When Partial Credit Is Acceptable

Not all failures are binary. In web development, a partially functional feature can still deliver value, unlike food safety or payroll where any failure is unacceptable. Recognizing the type of problem helps decide whether a 98% metric is tolerable.

Practical Guidance for Developers

1. Identify the failure cost – Determine whether a 2% failure rate is tolerable (e.g., cosmetic UI differences) or catastrophic (e.g., security, health, payments).
2. Measure your actual audience – General market share statistics may overstate support for your specific user base.
3. Implement progressive enhancement – Provide a baseline experience for all browsers, then layer advanced features behind feature detection.
4. Monitor edge‑case metrics – Track the experience of the excluded 2% to understand real‑world impact and prioritize fixes.
5. Communicate in odds, not percentages – Phrase reliability as “1 in 50 users may encounter an issue” to convey the significance of the minority.

Conclusion

A 98% success rate is a convenient shorthand, but it often hides unacceptable failures in high‑stakes domains. Robust engineering demands that we look beyond the headline percentage, measure impact on the actual audience, and design systems that gracefully handle the remaining edge cases.