Info Vendor-prefixed property without its standard counterpart
Why -webkit-transform should sit alongside a plain transform declaration, not replace it, and which properties this matters for today.
The validator flags a vendor-prefixed property (-webkit-, -moz-, -ms-, -o-) from a checked list — transform, transition, animation, box-shadow, appearance, user-select, box-sizing, backdrop-filter, mask, clip-path, filter, hyphens, and background-clip — that appears in a rule with no matching unprefixed declaration alongside it.
Example
/* Flagged: prefixed only */
.card { -webkit-transform: scale(1.05); }
/* Right: prefixed alongside the standard property */
.card {
-webkit-transform: scale(1.05);
transform: scale(1.05);
}Why it matters
Vendor prefixes were historically meant as a temporary bridge while a CSS feature was still experimental in a given browser engine, with the expectation that the unprefixed standard property would be included too — the prefixed version as a fallback for older engine versions, the plain property for everything else, including future browsers. Writing only the prefixed version, often copy-pasted from an old snippet or tutorial, means any browser that never implemented (or has since dropped) that specific prefix gets no styling at all. Most of the properties this check watches for have been standardized and broadly supported unprefixed for years, which usually makes the prefixed version alone entirely unnecessary — but pairing it with the standard property costs nothing and is the safer default.
Frequently asked questions
Do I still need vendor prefixes at all today?
For most of the properties this check covers — transform, transition, animation, box-shadow — no, modern browsers have supported the unprefixed version for years. A few properties (appearance, user-select, backdrop-filter in older Safari) still benefit from a prefixed fallback for wider compatibility.
Why does this only flag a specific list of properties?
Some vendor-prefixed properties, like -webkit-line-clamp or -webkit-font-smoothing, have no standardized unprefixed equivalent at all — flagging those as "missing a standard pairing" would be a false positive. The checked list is limited to properties that do have a real standard counterpart worth pairing with.