CSS Vendor Prefixes: Fixing Browser-Prefix Gaps

What a prefix gap actually is

Vendor prefixes date from a period when browser makers shipped experimental CSS under their own names: -webkit- for Safari and, later, Chrome; -moz- for Firefox; -ms- for Internet Explorer and old Edge; -o- for the old Presto-based Opera. The idea was that developers would use the prefixed version while a feature settled, then switch to the standard name. In practice many sites kept both forever, and some features never lost their prefix at all.

A CSS Checker prefix finding can mean one of three different things, and each needs a different response:

Only the first two affect visitors. The third is housekeeping. Keep that distinction in mind when you prioritise, because a long list of outdated prefixes can look alarming while being harmless, and a single prefix-only declaration on your checkout button can be the one that matters.

Finding the gaps in your own stylesheets

Start with the CSS Checker report, which scans your stylesheets for prefix coverage. Then confirm the findings in your source files, because the checker sees the compiled CSS the browser receives, while you need to fix the file you edit.

Search the source

A quick search shows how many prefixed declarations you have and where they live:

grep -rnoE "(-webkit-|-moz-|-ms-|-o-)[a-z-]+" src/ --include="*.css" --include="*.scss" | sort | uniq -c | sort -rn | head -40

Read the top of that list. If it is dominated by -webkit-transition, -webkit-transform, -moz-box-sizing or -webkit-border-radius, you are looking at legacy code that can simply go. If you see -webkit-line-clamp, -webkit-text-stroke or -webkit-tap-highlight-color, those are features that only exist in prefixed form, and they need to stay.

Check each property against real support data

For anything you are unsure about, look it up on Can I Use. The page for each property shows which browser versions need a prefix, and the "usage relative" view shows how much of your audience that represents. Pay attention to the notes under the table: a property can be listed as supported while one value, such as background-clip: text, has a separate history.

See the failure in the browser

In browser developer tools, select the element and open the Styles pane. Declarations the browser does not recognise are struck through, and Chromium shows a warning icon with "Invalid property name" or "Invalid property value". Firefox shows a similar warning. Safari's Web Inspector does the same, which is the view you most need, because Safari is where most real prefix gaps show up.

Choosing a browser list you can defend

Prefix tools do not guess. They read a list of target browsers, usually written in the browserslist format, and add only the prefixes those browsers need. The same list is read by Babel, PostCSS, Lightning CSS, Stylelint plugins and several bundlers, so setting it once keeps your CSS and JavaScript aligned.

The simplest sensible starting point is the built-in defaults query, which combines a usage threshold, recent versions, the Firefox extended support release and a rule to exclude browsers that no longer receive updates. Put it in package.json or a .browserslistrc file at the project root:

# .browserslistrc
defaults
not op_mini all

Then check what that list expands to, rather than trusting a query you have not read:

npx browserslist
npx update-browserslist-db@latest

The first command prints every browser version your query currently includes. The second refreshes the usage data the queries are based on; if you skip it for a long time, a build tool can keep adding prefixes for browsers that have long since faded away.

Use your own analytics where you can

Global usage figures are a proxy. A trade supplier whose customers use locked-down office PCs, a charity whose visitors skew towards older iPads, and a design studio whose visitors are all on the latest Safari have very different real audiences. Browserslist can read a usage file exported from your own analytics, so the list reflects your visitors rather than the world average. Even without that, look at your analytics browser report once a year and adjust the query if a group of older devices matters to you.

The fix, step by step

Setting up Autoprefixer or Lightning CSS

Most modern build setups already include one of these two tools, so check before adding another.

Autoprefixer through PostCSS

Autoprefixer is a PostCSS plugin. Vite, Next.js, Parcel and most starter kits run PostCSS automatically if a config file exists.

npm install --save-dev postcss autoprefixer

// postcss.config.js
module.exports = {
  plugins: {
    autoprefixer: {}
  }
};

With no options, Autoprefixer reads your browserslist file, adds prefixes the listed browsers need and removes outdated ones. To see what it will do before changing any files, run it from the command line against a single stylesheet and compare the output with the input.

Lightning CSS

Lightning CSS combines parsing, minifying and prefixing in one fast tool, and Vite can use it as its CSS transformer. It takes a targets setting, which you can build from the same browserslist query:

// vite.config.js
import { browserslistToTargets } from 'lightningcss';
import browserslist from 'browserslist';

export default {
  css: {
    transformer: 'lightningcss',
    lightningcss: {
      targets: browserslistToTargets(browserslist('defaults'))
    }
  },
  build: { cssMinify: 'lightningcss' }
};

Do not run both tools on the same CSS with different targets. You will get prefixes added by one and removed by the other, and a result that depends on plugin order.

Sites with no build step

A plain static site or a theme edited through a web interface has no build pipeline to hook into. You still have options: run Autoprefixer once from the command line on the stylesheet before uploading it, or keep a short, deliberate set of hand-written prefixes for the handful of properties that need them. What you should not do is copy prefix blocks from old tutorials, which is how most dead prefixes arrive in the first place.

Properties that still trip people up

Support changes over time, so treat the notes below as a checklist of where to look, and confirm the current state on Can I Use before relying on it.

Multi-line truncation, written correctly

.card-title {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 2;
  line-clamp: 2;
  overflow: hidden;
}

The unprefixed line-clamp line is there for the future; the prefixed trio is what does the work today in current browsers.

Gradient text with a fallback

.headline {
  color: #1a1a2e;
  background: linear-gradient(90deg, #1a1a2e, #3b5bdb);
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
}

Using -webkit-text-fill-color rather than setting color to transparent keeps the solid colour as the fallback for any browser that does not understand the fill property. For extra safety, wrap the clip and fill lines in a feature query for background-clip: text, so they are only applied where the clip itself works.

Using @supports instead of hoping

Prefixes answer "what is this feature called in that browser". Feature queries answer "does this browser support it at all". For anything visual that must degrade gracefully, a feature query is often the cleaner tool:

.site-header {
  background: rgba(255, 255, 255, 0.95);
}

@supports ((backdrop-filter: blur(8px)) or (-webkit-backdrop-filter: blur(8px))) {
  .site-header {
    background: rgba(255, 255, 255, 0.7);
    -webkit-backdrop-filter: blur(8px);
    backdrop-filter: blur(8px);
  }
}

The header is readable everywhere. Browsers that can blur get a lighter, more transparent background; browsers that cannot keep a near-solid one. Without the query, a see-through header with no blur can make navigation text hard to read over busy images.

Feature queries are also the right way to adopt newer layout features such as subgrid or container queries: write a working baseline first, then layer the enhancement inside @supports.

Keeping prefixes from creeping back

• Ban hand-written prefixes in source. Stylelint's property-no-vendor-prefix, value-no-vendor-prefix and selector-no-vendor-prefix rules flag them during editing. Add exceptions for the genuinely prefix-only features you rely on.
• Refresh browser data on a schedule. Run npx update-browserslist-db@latest as part of regular dependency updates so prefixes are added and removed based on current usage.
• Review the browser list yearly. Compare it with your analytics. Dropping a long-gone browser version can remove prefixes and fallbacks across the whole site.
• Keep a Safari check in your release routine. Most prefix problems are Safari problems. A two-minute look at key pages on an iPhone catches what automated checks miss.
• Be wary of pasted snippets. CSS copied from old tutorials, answers and code generators often carries prefixes from years ago, sometimes in the wrong order.

Once prefixes are generated rather than written, they stop being a thing you maintain. For the related problem of rules that browsers reject outright, see Fixing CSS validation errors; validators often list prefixed properties as warnings, and that guide explains which of those you can ignore.