Why Do Browsers Create Vendor Prefixes For CSS Properties

Why do browsers create vendor prefixes for CSS properties?

It's because the features were implemented by vendors before the specification reached its final release stage.

The vendor prefixes ensure that there are no clashes with changing functionality etc.

Originally, the point of vendor prefixes was to allow browser makers
to start supporting experimental CSS declarations.

Let’s say a W3C working group is discussing a grid declaration (which,
incidentally, wouldn’t be such a bad idea). Let’s furthermore say that
some people create a draft specification, but others disagree with
some of the details. As we know, this process may take ages.

Let’s furthermore say that Microsoft as an experiment decides to
implement the proposed grid. At this point in time, Microsoft cannot
be certain that the specification will not change. Therefore, instead
of adding grid to its CSS, it adds -ms-grid.

The vendor prefix kind of says “this is the Microsoft interpretation
of an ongoing proposal.” Thus, if the final definition of grid is
different, Microsoft can add a new CSS property grid without breaking
pages that depend on -ms-grid

Source.

Why people use CSS vendor-prefix although the specs clearly says don't

CSS 3 spec is newer than CSS 2.1, so let's skip what 2.1 says.

The spec says implementations —that refers to browsers, not stylesheets— should not require vendor prefixes. That's different from whether or not they do. Some browsers do require prefixes for some styles.

The thing is the W3C's CSS Working Group, who write the CSS spec, do not actually have power over browser developers — the browser developers have to choose to follow the spec (in part or in full). What's exciting is that more and more the main browsers are falling into line with the spec, and vendor prefixes are needed less and less.

The vendor-prefixed properties you need to provide depends on what browsers you support. Within a given browser, the requirements often vary by version. Newer versions of browsers for the most part require fewer vendor CSS properties than older versions of the same browser.

Snippets found online don't always age well. For example

-webkit-transition: all 4s 
-moz-transition: all 4s ease;
-ms-transition: all 4s ease;
-o-transition: all 4s ease;
transition: all 4s ease; 

would typically be considered overkill these days. Always check the date on bits of code found online. On SO, checking rep can help you distinguish between workable answers and best answers.

There's a whole separate question of how dropping support for old browsers related to web accessibility. Won't get into that here, but there are some people who say that choosing to only support more recent and/or popular browsers is inherently problematic.

Autoprefixer can be configured to target exactly the browsers you want to support. It adds only the vendor-specific CSS needed to meet the need you specify. By default, Autoprefixer uses the Browserlist default. With that setting, no vendor-specific code is needed to support border-radius: 10px 5px and transition: all 4s ease. You can see that by running your two rules through https://autoprefixer.github.io/, "filtered" by > 0.5%, last 2 versions, Firefox ESR, not dead. You can see which browsers that covers at https://browserl.ist/?q=%3E+0.5%25%2C+last+2+versions%2C+Firefox+ESR%2C+not+dead

In practice, a lot of people simply do not write vendor-specific CSS, relying on Autoprefixer built into their build tooling. For example, you might have a Gulp or webpack setup that automatically runs your stylesheets through Autoprefixer. If that's new to you, a good starting point might be postcss-cli, the command line tool for PostCSS.

npm install -g postcss-cli autoprefixer
postcss my-styles.css --use autoprefixer --dir output-directory

What is the purpose of CSS prefixes?

The original purpose of vendor prefixes was to give vendors the ability to add their own non-standard features for use in their CSS implementations. However, most of them are used for experimental versions of things that eventually become standards.

If an experimental property is unprefixed, it implies that it's the correct, standard version of a property. If every browser renders it differently, then there isn't much of a standard. Instead, a browser avoids implementing an unprefixed property until it's sure that it's done so according to the standard, then it starts supporting the unprefixed property as a way of saying it supports this particular standard correctly.

Not every feature has a prefix; indeed, a vendor creates a prefix only if it deems it necessary.

Why do browsers need vendor prefixes for CSS3? What is stopping them from just using the standard CSS3 properties?

CSS3 has not been formally adopted as a complete standard yet—it is still a draft proposal.

Vendor specific tags allow the vendors to begin to implement CSS3 draft standards or proposed ideas for CSS3 now using experimental implementations, while ensuring that their current rendering with these proprietary tags can be distinguished in the future from their rendering of the actual CSS3 tag as per the final spec, even if that is different.

What CSS3 features still need vendor prefixes?

There is a great site which allows you to check out support of any css property by most modern browsers. It also shows info about vendor prefixes (if they are needed).
This site is named "Can I use" - http://caniuse.com

Why are there vendor prefixes in CSS3?

This has been asked before, but the short answer is that CSS3 is not a finished product. CSS 2.1 wasn't published until 2011, and only a handful of CSS3 modules have even reached the level of a formal recommendation, so it's premature to talk about a CSS3 specification that is universally implemented. Thankfully, modern browser makers are helping to push things forward and are helping to craft the standard which follows the lead of real-world practice. As they move closer to general standards, the prefixes are dropped.

---

Related Topics