What is the reason to put prefixes in new CSS features?

Question

Is there a valid reason for the browsers to prefix new CSS features, instead of letting the webmasters use the non-prefixed version?

For example, a sample code for the background gradient looks like:

#arbitrary-stops {
  /* fallback DIY*/

  /* Safari 4-5, Chrome 1-9 */
  background: -webkit-gradient(linear, left top, right top, from(#2F2727), color-stop(0.05, #1a82f7), color-stop(0.5, #2F2727), color-stop(0.95, #1a82f7), to(#2F2727));

  /* Safari 5.1+, Chrome 10+ */
  background: -webkit-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Firefox 3.6+ */
  background: -moz-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* IE 10 */
  background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Opera 11.10+ */
  background: -o-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
}

What's the point in forcing webmasters to copy-paste the same code four times to have the same result?

---

Note: one of the reasons often quoted is that prefixed styles are intended to be temporary while either the browser does not implement the spec correctly, or the spec is not definitive.

IMO, this reason is a nonsense:

• If the browser engine does not implement the spec correctly, the browser will not be compliant, no matter if it does not implement it in a non-prefixed form or it does not implement it in a prefixed form.
• If the spec is not definitive, it may matter when there were previous implementations with the same name. For example if CSS2 had linear-gradient, but CSS3 was intended to extend linear-gradient with additional features, it would be clever to temporary prefix the new, draft, implementation by -css3-<style> differentiate between the working CSS2 one, and the experimental CSS3 one. In practice, CSS2 doesn't have linear-gradient or other CSS3 novelties.

I would also understand if different browsers had different implementation formats: for example let's say Firefox required, for text shadow, <weight-of-shadow distance-x distance-y color>, while Chrome required <distance-x distance-y weight-of-shadow color>. But actually, this is not the case; at least all new features of CSS3 I've used so far had the same format.

Answer 1

According to this W3C note:

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

---

You can follow up the state of the CSS here and here.

Answer 2

I would also understand if different browsers had different implementation formats ... [b]ut actually, this is not the case; at least all new features of CSS3 I've used so far had the same format.

This tells me that you have not been playing this game for long enough.

The problem is that web browsers never implement new features in the same manner. It is common to see a browser implement features that have not been standardized, and the result is that everything acts differently on different browsers.

Not only that, new features are often buggy (we'll avoid calling IE out by name), and so even though the syntax for various elements is the same, the result is different.

This causes a headache for developers who are tring to use new features. After they finish writing their stylesheet, they quickly realize that it renders differently on different browsers for inexplicable reasons.

Before prefixes came along, developers were forced to rely on detectable differences between browsers, often by exploiting errors in the CSS parser. This resulted in abominations such as this:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

These sorts of hacks were the result of a developer's attempt to customize their stylesheet for each browser, using any sort of outlandish methods they could find.

By standardizing prefixes, it allows developers to use features that are not stable across different browsers. The -moz- and -webkit- prefixes make it abundantly clear that the author is trying to provide a style that should be applied only in certain web browsers.

Once features become stable and browsers start acting the same, you can remove the prefix and declare the feature once.

I think it is important to realize that prefixes do NOT mean that you must declare styles once for every browser. Prefixes mean that must declare additional styles any time that you find a web browser is not conforming to a standard. For example, instead of your above code, you should start with:

 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

If you suddenly realize that Microsoft is unable to compute a linear gradient correctly, then you can add in a prefix to fix the problem on IE:

 /* Friggin IE */
 background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

Suddenly your page looks the same in every browser, despite the fact that one of them did things differently.

You will find that this has been covered in a very comprehensive manner in this article on A List Apart.

Answer 3

If the browser engine does not implement the spec correctly, the browser will not be compliant, no matter if it does not implement it in a non-prefixed form or it does not implement it in a prefixed form.

The difference is that the browser won't break compatibility when it does become compliant. If the browser's behaviour is different to the spec, then they won't break old code when they change it- because it's listed under a new name.