# Vendor prefixes are not developer-friendly

DevFeed: [Vendor prefixes are not developer-friendly](<https://devfeed.tech/articles/vendor-prefixes-are-not-developer-friendly-21676.md>)

Original publisher: [Read original article](<https://paulirish.com/2012/vendor-prefixes-are-not-developer-friendly/>)

Author: Paul Irish

Published: 2012-03-05T07:06:00Z

Content type: article

Language: en

Sources: [Paul Irish](<https://devfeed.tech/sources/paul-irish.md>)

Topics: [CSS](<https://devfeed.tech/topics/css.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [web-standards](<https://devfeed.tech/topics/web-standards.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [compatibility](<https://devfeed.tech/tags/compatibility.md>), [cost](<https://devfeed.tech/tags/cost.md>), [css](<https://devfeed.tech/tags/css.md>), [developer](<https://devfeed.tech/tags/developer.md>), [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [standards](<https://devfeed.tech/tags/standards.md>), [tool](<https://devfeed.tech/tags/tool.md>), [web-developers](<https://devfeed.tech/tags/web-developers.md>)

## AI overview

The article argues that CSS vendor prefixes conflict with practical developer workflows. It describes inconsistent use of prefixed properties, the maintenance burden of updating production CSS, and how tools tend to prioritize unprefixed declarations, potentially undermining the purpose of prefixes.

## Source excerpt

or... The premise of prefixes makes unrealistic demands on how developers maintain sites There's a lot of conversation about making prefixes work (by changing policy), but I believe they already are at odds with the developer workflow. In this proposal I hope to show that: prefixes are not developer-friendly recent features would have been in a much better state without prefixes implementor maneuverability is not hampered without prefixes The developer experience If I'm using a feature that's prefixed, I have a choice of using a tool to help me manage outputting the various prefixes I need or I'll do it myself. Based on my informal poll last week it looks like 40% of developers are not using tools. Without tool usage, authors are not including -ms-, -o- or the unprefixed variants. Page 4 of Mozilla's prefix report verifies this; developers don't write necessary prefixed properties about half the time (e.g. -o-transform) and in fact, they already write out the unprefixed variant well before the spec goes to CR (and do this well before adding in -ms- or -o- compatibility). Data summarizing prefixes' failure with developers [Mozilla's prefix report, page 4] This matches my experience as well. I don't want to return to this code to maintain it, so I'm going to add the unprefixed version. There is less of a cost to me leaving the unprefixed version and assuming I won't need to change it vs. returning to my CSS of shipped-to-production work to add unprefixed variants each time a feature hits CR. Any successful evangelization plan for prefixes relies on tools, but all tools prioritize the unprefixed state. prefix-free, compass, and css3 please (I'm a tool vendor, too) all heavily suggest starting with the unprefixed state. So any successful evangelization push will just result in the unprefixed version being 100% deployed from the get-go, which ties implementors hands anyway and defeats the purpose of the prefix. I don't have data to show that developers are not returning to