Having recently seen yet another site by a high profile shop (cognition) [1] making the same mistake, this need to be repeated again and again. When using vendor-prefixed properties together with the non-prefixed property, the cascade matters. Some months ago I noted it in an email to the CSS-Discus mailing list. I’ve probably mentioned it a few times in the past. Roger Johansson noted it recently, others mention it implicitly or explicitly.

But it is worth repeating: when using vendor-prefixed properties (such as -moz-border-radius or -webkit-box-shadow or -o-transform) and the equivalent CSS properties as specified in an official spec, the CSS property should be listed last. This leverages the cascade [2]. Properties are evaluated and applied in order of their appearance in the stylesheet. Putting the official property last in your list ensures that it will be applied by browsers that support it correctly and / or completely.

Consider these 2 WebKit specific code snippets (demo page, view in Safari 5 or a recent Chrome build)

.a {
	-webkit-border-radius: 20px;
	border-radius: 5px/20px;
	}
.b {
	border-radius: 5px/20px;
	-webkit-border-radius: 20px;
	}

Both snippets are similar on the surface, but versions of WebKit that support the un-prefixed property will not apply the correct one (border-radius) when the second code snippet is used. Instead -webkit-border-radius is used (note that the -webkit-prefixed property did not support multiple values for the border-radius shorthand and has some other minor differences). Safari 5 and recent Chrome builds support the CSS3 notation, but also support the -vendor-prefixed one (for backwards compatibility reasons, but also because a number of third-party apps or Dashboard widgets may depend on the vendor-prefixed property – WebKit being a core part of OS X is used by other applications). Similarly, Mozilla recently finished implementing support for the non-prefixed box-shadow property. In this case, the computation of the blur radius is slightly different from the prefixed -moz-box-shadow – following feedback on the relevant spec.

When using those vendor-prefixed, experimental properties, authors most certainly want to use the officially specified behaviour if available. There are cases where specifying a non-prefixed property can be detrimental. Currently, the highly experimental CSS gradients come to mind; first implemented by WebKit, it was then implemented by Gecko. This led to serious discussions about the syntax and the draft of a spec; that is certainly not yet set in stone however, and the syntax will likely evolve further in the near future. For vendor-prefixed properties that are part of relatively safe specs (such as the CSS Backgrounds and Borders Module Level 3) including the non-prefixed syntax is a must – for most part, rendering engines already support the official property in their most recent (beta) release. To make vendor-prefixed and official properties co-habit safely, make sure, as an author, to specify the official, non-prefixed property and syntax last and let the CSS cascade do its work.

notes
  1. They are far from the only ones; there are numerous code samples, examples and demos out there making the same mistake. Even PPK does it in his rant against vendor-prefixed properties.
  2. Relevant part of the CSS spec: CSS2.1:6 6 Assigning property values, Cascading, and Inheritance (and in particular CSS 2.1:6.4.1 Cascading order), and it is also implied in the rules for handling parsing errors.