98% Support Still Needs a Door

The sharp point in Hugo Barrera's essay is that a percentage can look excellent while still describing real people locked out.

Hugo Barrera's "98% isn't very much" is a short web-development essay with a useful sting: a support number that sounds excellent can still be a weak promise when the feature is part of basic access. His point is not that modern browser features are bad. It is that a website that works for nearly everyone can still fail a huge number of people, and that global support statistics may not match the audience actually visiting a specific site.

My read is that this is the right way to think about browser compatibility in 2026. I want the modern web platform. I also want teams to stop treating "widely supported" as if it automatically means "safe for my users." The adoption decision should depend on blast radius, audience analytics, and whether unsupported browsers get a graceful path instead of a broken page.

Answer Snapshot

Question	My read
What happened?	A July 3, 2026 WhyNotHugo post argued that 98% support is not enough when the missing 2% means real users cannot use a site.
Why it matters	Browser support percentages compress too much: global usage, core-browser support, local audience mix, and fallback quality are different questions.
Who benefits if teams handle this well?	Users on older, managed, niche, mobile, assistive, or constrained browsing setups, plus frontend teams that want modern CSS without surprise regressions.
My thesis	A new web feature is safe only when the unsupported path is acceptable. If failure breaks the core experience, 98% is not a finish line.
What I am not arguing	I am not saying every site must support every old browser forever, or that CSS nesting is bad. I am saying the support bar depends on what breaks.

The Number Is Doing Too Much

Barrera's strongest move is to separate bonus outcomes from baseline expectations. A 98% success rate can sound amazing for a difficult achievement, but it sounds very different when the expectation is basic reliability. Applied to the web, the missing percentage is not an abstract remainder. The source post notes that a feature working for 98% of the population can still leave out roughly 150 million people.

The more practical warning is that "98% of the population" may not mean 98% of a site's actual audience. Barrera says he checked one client's browser distribution while considering whether to remove an SCSS pipeline, and found that over the prior year only about 70% of visiting browsers supported the newer CSS features in question. That is the part I find hardest to hand-wave away. The decision was not about a generic web user. It was about that site's real traffic.

This is why I dislike compatibility arguments that stop at a single percentage. The number is useful, but it is not the decision. The decision is whether the feature is decorative, progressive, recoverable, or load-bearing.

A global average can hide the audience that actually visits your site. The local distribution is often the number that matters.

CSS Nesting Is a Good Test Case

CSS nesting is a useful example because it is not a gimmick. MDN's guide describes it as browser-parsed CSS, not precompiled Sass, and says it can make stylesheets easier to read, more modular, and sometimes smaller. Chrome's developer documentation makes a similar case around organization, reduced repetition, and refactoring.

So the pro-adoption argument is real. Native nesting removes a build-step dependency for some sites, gives authors a familiar way to group related selectors, and is now part of the modern platform conversation. Baseline also gives developers a shared language for support: newly available means all core browsers support a feature, and widely available means 30 months have passed since that interoperable date.

But the details still matter. Sass's 2023 writeup explained that native nesting is not identical to Sass nesting, including differences around :is() specificity and selector suffix behavior. The Sass team said it would not change existing valid Sass output to emit browser-incompatible CSS until native nesting reached 98% global browser market share. That caution is not nostalgia. It is compatibility discipline from people who understand how much CSS sits in production.

As of the Can I Use CSS Nesting page I inspected, the feature showed 90.81% global usage support when combining full and partial support, with usage statistics based on StatCounter data for June 2026. That is high enough to be interesting and low enough to prove Barrera's point: the label "modern" does not tell me whether a site's unsupported path is acceptable.

Baseline Is Not a Permission Slip

I like Baseline because it replaces vibes with a common vocabulary. It makes the platform easier to discuss, lint, and teach. The problem starts when teams turn that vocabulary into a yes/no permission slip.

The ESLint CSS use-baseline rule documentation is careful about this. It says Baseline can help interoperability, but testing is still required, especially when an audience uses browsers outside the core set. It also notes that accessibility testing is still required because Baseline does not track assistive-technology support, and it explicitly leaves room for @supports, fallbacks, and progressive enhancement.

That is the version of Baseline I trust. It is a good input to an engineering decision, not a replacement for one. A feature can be Baseline and still be the wrong choice for a public form, a checkout flow, an internal enterprise app with locked-down browsers, or a site whose audience over-indexes on old mobile devices.

My rule of thumb is simple: the worse the failure mode, the higher the support bar. If unsupported browsers get a readable page and a working path, I can move faster. If they get a broken core experience, the percentage needs to be much higher.

The tradeoff is not old web versus new web. It is developer convenience weighed against the cost of excluding users from basic functionality.

The Public Reaction Is Split

The developer conversation around native CSS nesting shows the real split. In a Reddit webdev thread about whether native CSS nesting was safe to use, one concern was straightforward: if nesting is fundamental to the stylesheet, unsupported browsers may lose far more than a minor polish layer. Other commenters were comfortable moving ahead when their support policy was limited to recent Chrome, Edge, Firefox, and Safari versions.

That split is not irrational. It is audience-dependent. A private project with a narrow browser policy can tolerate a different risk than a public information site, a school system, a government-adjacent service, or a product with customers on managed hardware. The mistake is pretending there is one universal threshold.

The skeptical side also has a maintainability argument. Piccalilli's "CSS nesting: use with caution" argues that nesting solves a developer problem more than an end-user problem, warns about specificity gotchas, and recommends keeping nesting shallow if you use it. I do not share the most absolute version of that critique, but I find the pressure useful. A feature that improves authoring can still make runtime support and code comprehension worse if applied carelessly.

A Better Adoption Checklist

Question	What I would check
Is this enhancement or foundation?	If the feature only improves layout polish, a fallback can be simple. If it controls navigation, forms, purchasing, reading, or authentication, the bar rises.
What happens without support?	Test the unsupported path directly. Do users get usable content, a reduced layout, or a broken interface?
What does real traffic say?	Look at actual browser and device analytics for the audience, not only global compatibility tables.
Can the feature be isolated?	Use @supports, build output, progressive enhancement, or simpler CSS so unsupported browsers avoid the fragile path.
How will regressions surface?	Keep compatibility checks, analytics, support reports, and accessibility testing close to the release process.

This checklist is not glamorous, but it is the difference between modernizing a codebase and quietly firing a slice of the audience. The goal is not to freeze the web. The goal is to make feature adoption legible: what improves, what breaks, who is affected, and how the team will know.

The operational answer is detection, fallbacks, analytics, and accessibility review, not a single percentage copied into a release decision.

My Bottom Line

Barrera's post works because it pushes on a lazy shortcut without turning into anti-progress nostalgia. I want teams to use native CSS nesting, container queries, :has(), and the rest of the platform when they make products better. I also want them to ask what happens to the people outside the happy path.

For me, 98% is not "good" or "bad" by itself. It is a prompt to ask sharper questions. Is the remaining 2% actually tiny for this site? Is the audience distribution known? Is the missing support concentrated in a group the product claims to serve? Does the page degrade gracefully? If the answers are weak, then "widely supported" is not enough. It is just a nicer-sounding way to leave someone at the door.

Originally published at markhuang.ai