Why “93% support” isn’t a green light
When a CSS feature like container queries claims ~93% global browser support, that single figure rarely tells you whether you should actually ship it. The number is a useful starting point, but it’s an average of a worldwide sample that likely doesn’t match your product’s real traffic. Instead of treating caniuse percentages as a hard threshold, I weigh three factors before adopting a modern feature.
The fallback experience
Some features degrade gracefully, others don’t. Consider text-wrap: pretty: in a browser that doesn’t support it, the declaration is simply ignored, and the text renders with default line-wrapping. The user misses out on the orphan-avoiding enhancement but suffers no broken layout or inaccessible content. This is a textbook progressive enhancement — even 20% support wouldn't be a blocker.
Other features fail harder. overflow: clip lets you clip on one axis without creating a scroll container, which is handy for situations like keeping an image inside a bounded area:
If the browser doesn’t understand clip, it falls back to visible, so the content spills out. For decorative overflow, that’s often acceptable. But it can create real problems when the clipped element overlaps adjacent content:
Here, overflow-y: clip would keep the overflowing image hidden in a supported browser, but in an older one the image ends up covering subsequent text, making it unreadable. That’s a dramatic difference in experience based purely on the browser.
The lesson: always ask what does the unsupported experience look like? Optional enhancements are fine with low support; features that produce broken layouts need more scrutiny.
Repairing the fallback with CSS
When the default fallback is unusable, you can often patch it with standard CSS. The cascade works in your favour here — later declarations overwrite earlier ones in supporting browsers, while unsupported values are dropped:
.thing {
overflow: hidden;
overflow: clip;
}In a browser that recognizes clip, the overflow: hidden gets replaced. In one that doesn't, clip is ignored and hidden applies — a safe intermediate. For more complex cases, @supports lets you specify a different set of styles. Just be mindful that @supports checks for feature recognition, not complete support, so its results aren’t always as clean as they seem. The objective is not to replicate the modern UI precisely, but to guarantee a reasonable fallback.
Where caniuse numbers come from
Caniuse’s percentages are aggregated from Statcounter, which tracks visits across roughly 1.5 million websites. That yields a solid worldwide view, but your audience is rarely “the world”.
This blog’s analytics look notably different from the global mix. Firefox usage is about 2.5x higher among Tech Report readers than in the overall sample, for example. Internet Explorer shows up in my traffic at a negligible 0.0000018% rate over three months — about a single visitor. Compare that with a past role at Khan Academy, where school-lab machines running older browsers drove a meaningfully larger IE share. Products serving education settings, healthcare portals, or other contexts with dated hardware see vastly different distributions. A baseline like “~93% global support” is a starting point, not a final verdict — it’s always worth checking the analytics for your own property.
Measuring the actual cost
Even a good feature that breaks the page can be worth shipping when the stakes are low for the affected users. Three questions help calibrate that tradeoff:
- Fallback condition: A failed layout render can obscure content, as with
overflow: clip; a missing enhancement may simply look dated. - Audience skew: Does your product’s browser mix lean toward the modern end of the global average, or toward older machines?
- Consequences of failure; Is the worst-case outcome an irritated visitor, or a missed medical appointment?
For a yacht rental marketplace, declining to support an aging browser can be a purely financial calculation — the cost to engineer the legacy path isn’t worth the revenue from that 1% slice. But for ClicSanté, Quebec’s government booking portal for vaccines and lab tests, low support is genuinely harmful: inaccessible care has a tangible societal cost. In services with real-world consequences, it’s not a number to discount casually.
Putting the formula to work
I run my own blog, which relies on container queries for a newsletter-archive page. Caniuse’s global 93% support looks roughly like 97% for my visitors, using my Fathom analytics as a base. That’s solid, but that’s not the whole story — here’s how the other two factors played out for this specific implementation:
Fallback: I simulated an unsupported browser by deleting all the CSS inside every container query block. The card-based layout remains readable, yet the fallback UI is clearly less polished — the sender email overflows into the domain line, and my cartoon mascot stretches itself out, wasting a lot of space next to the text. The trade-off feels acceptable for a page whose goal is to present written content.
Harm: Tutorials are not urgent, life-sustaining resources. A slightly off-looking layout is not a crisis — no reader is going to miss a critical deadline because a container query didn’t fire.
Combining those factors — a ~97% supported audience, a degraded-but-functional fallback, and essentially no negative consequences from rare breakage — yields a clear answer for my blog: container queries are safe to ship.
That verdict isn’t a universal one. The same feature could be a poor choice for a commercial product with a broader, older user base, or for a public-service portal where every percentage point of support matters. Your decision should never rely on the raw caniuse percentage in isolation; measure the experience in old browsers, understand your own traffic, and assess the real harm of an imperfect experience for the edge cases.
Pass/fail tests don’t survive contact with the real world
Most engineers default to a clean threshold when deciding whether a feature is safe to use. Something like: “if over 97% of browsers support it, ship it.” That instinct is understandable—a single number feels objective and defensible. The problem is that browser support doesn’t actually work like that.
The reality is significantly more nuanced. Usage data shifts continuously, global stats rarely match your product’s audience, and support can depend on flags, prefixes, or specific sub-features. A single percentage point rarely tells the whole story, even if it points in the right direction.
That said, the decision process doesn’t have to be pure guesswork. Over time, I’ve distilled the way I think about these trade-offs into a repeatable framework. It won’t eliminate the murkiness—decisions like this always involve some judgment—but it should give you more confidence when you’re weighing the costs and benefits of a particular feature.
Support data is a starting point, not a verdict
Can I Use and similar tools give you raw numbers, but those numbers are only snapshots. They aggregate visits across millions of sites, which often has nothing in common with your user base. If you serve an internal enterprise tool, your baseline is completely different from a consumer-facing site with global traffic.
The real question isn’t “what’s the global support rate?” It’s “what does my audience’s support look like?” That means checking your own analytics, looking at your most common browser versions, and filtering the data to your actual traffic before you make a call. A feature might be perfectly safe at 92% across the web but risky if your own users skew toward one browser or platform.
A practical method for weighing the decision
When a feature sits in a gray zone, I tend to work through a handful of considerations in rough order:
- How progressive is it? Can the feature degrade gracefully? If it’s purely cosmetic, adding an unsupported CSS property is low-risk—browsers simply ignore it. If it’s structural or functional (like a new API), the fallback story matters a lot more.
- Who experiences the problem? If the gap affects a tiny slice of your traffic, it often costs more engineering time to build and maintain a workaround than to let those visitors get a slightly degraded experience.
- What are you shipping? For an internal tool accessed by your team on modern laptops, support thresholds matter far less than for a public marketing site. Match your risk tolerance to the context.
- What does the fallback cost? Polyfills, alternative syntaxes, and feature detection all add maintenance burden. Sometimes the fallback is trivial; sometimes it’s an ongoing tax on every future change to that component.
There isn’t a magic number that resolves this for you. The framework exists to force you to explicitly consider each of these angles rather than reacting to a single global percentage.
Talk to actual people
Another tool in the toolbox is direct feedback. If you’re unsure whether it’s safe to drop support for a legacy browser, try reaching out to your heaviest users or checking community forums. Often the people who would be affected are vocal about it, either in your issue tracker or on social media. Silently making a decision based on a stat sheet risks breaking something for a user who would have gladly spoken up if asked. When in doubt, a quick poll or a deprecation notice can give you better information than any database.
