Every tool in this space checks your source code before it is bundled. None of them check the stylesheet a visitor downloads - including the parts added by your CMS, your theme and your third-party embeds.
The tooling for browser support is mature and good: Browserslist, ESLint and Stylelint rules for Baseline, editor hints, and support data in DevTools when you select a property. Every one of those runs on code you wrote, in a project you control, before the build.
The CSS a visitor receives is frequently not the CSS you wrote:
None of that passes through your linter. On a WordPress, Shopify or Webflow site there may be no build step to lint at all.
The features most likely to ship without a fallback, and the browsers that lag on them:
| Feature | Typically the last to support it |
|---|---|
:has() | Firefox |
| Container queries | Firefox, older Safari |
subgrid | Chrome and Edge, until relatively recently |
color-mix(), oklch() | Across the board until 2023 |
text-wrap: balance | Safari |
Object.groupBy, Promise.withResolvers | Everything before late 2023 |
URLPattern | Firefox and Safari, for a long time |
Popover API, inert, <search> | Safari and Firefox |
Baseline is the useful vocabulary here. Widely available means the feature has been interoperable across the major engines for roughly two and a half years and is safe without a fallback. Newly available means it just landed everywhere and your older visitors will not have it. Limited means at least one major engine is missing it entirely.
Pick a target explicitly - Baseline Widely available is a sane default for a public site - and check what you ship against it rather than against whichever browser you happen to develop in.
@supports (color: color-mix(in srgb, red 50%, blue)) {
.card { border-color: color-mix(in srgb, var(--tint) 40%, transparent); }
}
/* fallback first, so unsupported browsers get something */
.card { border-color: rgba(79, 142, 247, 0.4); }Use the build-time tools too
If you have a build step, Stylelint and ESLint with Baseline rules will catch problems before they ship, which is strictly better than catching them afterwards. Runtime checking is for what those tools cannot see: themes, plugins, embeds and anything on a site with no build pipeline at all.
A shared vocabulary from the WebDX Community Group for describing cross-browser support. Newly available means a feature has just become interoperable across the major engines; Widely available means roughly thirty months have passed since then, so it is safe for most sites without a fallback.
You can, and it is the right reference. The problem is knowing which features are on your page in the first place - particularly the ones added by a theme, a plugin or an embed that you did not write and would not think to look up.
For code in your repository, yes, and it should be your first line of defence. It cannot see CSS injected by a CMS theme, a page builder or a third-party widget, and on a site with no build step there is nothing for it to run against.
No. Use it deliberately, with @supports guards or a fallback declaration first, and know which of your visitors get the fallback. The point of checking is to make that an informed choice rather than an accident.
A scan of the CSS and JS your live page actually serves - including theme and plugin code - against a browser target you choose.
One email when it is ready. No newsletter, no sharing, unsubscribe in one click. Questions: support@hakeemify.com