Detailed explanation
Browser-specific CSS prefixes are vendor-labelled property names, values, or selectors, such as -webkit-user-select or the older display: -ms-flexbox. Browsers historically used prefixes to expose experimental implementations before a specification or implementation stabilised. Some prefixes still matter for particular browser versions, but a newer feature does not automatically need them. I normally write standard CSS, define the browsers the project must support, and let build tooling generate the compatibility declarations. This avoids cluttering source files with guesses about browser support.
Autoprefixer is a PostCSS plugin that processes CSS during a build. PostCSS parses CSS into an abstract syntax tree, which plugins can inspect and modify. Autoprefixer uses compatibility data from Can I Use and browser targets resolved through Browserslist to decide which prefixes are necessary. Targets can be configured in a .browserslistrc file or the browserslist field in package.json. For example, a project might use a query such as "> 0.5%, not dead", although real targets should reflect product requirements rather than a copied default.
For .box { display: flex; user-select: none; }, the generated declarations depend on those targets and the installed compatibility data. Older targets can require display: -webkit-box or display: -ms-flexbox, while modern targets may need neither. Some targets may still require -webkit-user-select. Therefore, the example output is illustrative, not a fixed transformation. When generating fallback declarations, the standard declaration generally comes last so a browser that supports it can use it. Autoprefixer can also remove outdated prefixes that are unnecessary for the configured targets.
The main benefit is consistent, maintainable compatibility work: developers express intent in standard CSS while automation handles known prefix differences. However, prefixes do not implement missing browser capabilities, fix every browser bug, or guarantee identical layouts across older implementations. I still check feature support, test important flows in target browsers, and use fallbacks or @supports where appropriate. In an interview, the strongest answer connects prefixes, explicit browser targets, build-time processing, and the limits of automation rather than simply saying that Autoprefixer makes CSS work everywhere.
Key points to remember
- Vendor prefixes apply to properties, values, and selectors, not just property names.
- Autoprefixer is a build-time PostCSS plugin, not a runtime browser polyfill.
- Browserslist targets and compatibility data determine the generated prefixes.
- Write standard CSS; let Autoprefixer add required prefixes and remove obsolete ones.
- Test target browsers because prefixes cannot solve all compatibility problems.
Common mistakes candidates make
- Adding every known vendor prefix manually without checking whether target browsers need it.
- Assuming Autoprefixer always produces the sample flexbox prefixes, regardless of browser targets.
- Treating Autoprefixer as a polyfill that enables completely unsupported CSS features.
Likely follow-up questions
How do you configure Autoprefixer in a project?
Install PostCSS and Autoprefixer, then register Autoprefixer in the build tool's PostCSS configuration if it is not already integrated. Define Browserslist targets in package.json or .browserslistrc, and verify that the build actually processes your CSS.
How is Autoprefixer different from a polyfill?
Autoprefixer rewrites CSS to use known prefixed implementations available in target browsers. A polyfill supplies missing functionality where feasible; Autoprefixer cannot create a layout engine capability that a browser does not have.
What should you do when prefixes are not enough?
Provide a usable baseline layout or style, then progressively enhance it with supported features. Use @supports for feature-dependent CSS and test in target browsers, since accepting a declaration does not guarantee bug-free rendering.
Interview tip: Explain the standard-CSS-to-PostCSS-to-targeted-output workflow, then mention that the example output changes with browser targets.