Ordering of Vendor-Specific CSS Declarations

Ordering of vendor-specific CSS declarations

The best practise is undisputedly to have the unprefixed property last:

.foo {
    -moz-border-radius: 10px;    /* Mozilla */
    -webkit-border-radius: 10px; /* Webkit */
    border-radius: 10px;         /* W3C */
}

Whichever is last out of -webkit-border-radius and border-radius will be the one that's used.

-webkit-border-radius is the "experimental" property - the implementation may contain deviations from the specification. The implementation for border-radius should match what's in the specification.

It's preferable to have the W3C implementation used when it's available, to help ensure consistency between all the browsers that support it.

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.

Do we have to use non-standard/browser specific CSS vendor prefixes anymore?

It really depends on which features and which browsers you want to fully support. Even now some browsers are lagging.

Here is a really excellent guide: http://caniuse.com/

a property without vendor prefix followed by vendor prefixed properties in CSS3

The code snippet you provided is considered a good practice because it is (hopefully) forward and backward compatible...

Basically with a non-standard implementation each browser may implement the property a little differently hence the prefixes. If all goes well, eventually the different browsers will standardize the property and will (hopefully) render it the same way.

The prefixed versions will work for the time being and (hopefully) by the time the browsers standardize the property and remove the prefix the non-prefixed version will work.

I know the seeing "hopefully" above isn't that encouraging, if you want your CSS to be bullet proof, don't use the new properties until they're standardized or design your stuff to degrade gracefully.

Some css3 properties, like border-radius, are somewhat standardized and will render properly without the prefix, but not every internet user keeps their browser up to date, so it may be a good idea to continue to use the prefix for a while.

On the other hand there are some properties that Firefox will render without a prefix that Chrome will not, like animation and @keyframes. In this case using the prefixed version followed by the non-prefixed version makes perfect sense.

.myClass {  position: relative;  -webkit-animation: myAnimation 3s; /* Chrome will use this */  animation: myAnimation 3s; /*Firefox will ignore the -webkit- property and use this */}@-webkit-keyframes myAnimation { /* Chrome will use this */  from {    background: red;    top: 10px;  }  to {    background: blue;    top: 100px;  }}@keyframes myAnimation { /*Firefox will ignore the -webkit- property and use this */  from {    background: red;    top: 10px;  }  to {    background: blue;    top: 100px;  }}

<div class="myClass">Hello World</div>