Why standard rule must be at last?

Question

We use css rule like this...

-moz-border-radius: 8px;
-webkit-border-radius: 8px;
-o-border-radius: 8px;
border-radius: 8px;  /* this must be at last ? */

Why should I not use it at first like this...

border-radius: 8px; /* why not to use at first ? */
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
-o-border-radius: 8px;

Update

Can anyone show me an example of error occuring using it at first?

Answer 1

When writing CSS3 properties, the modern wisdom is to list the "real" property last and the vendor prefixes first:

.not-a-square {
  -webkit-border-radius: 10px;
  -moz-border-radius: 10px;
  border-radius: 10px;
}

Why is this method of ordering properties so commonly taught? Here is what it would look like "the wrong way":

.not-a-square {
  border-radius: 10px;
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
}

Even doing it "the wrong way", won't the border radius be the same no matter what, forever? A quick investigation might lead you to conclude that it will, and this ordering of properties is rather nonsense.

The Long Long Ago: None of the properties are supported, order doesn't matter. The Past: Only vendor prefixes are supported, order doesn't matter. The Now: Both vendor prefixes and actual property are supported. If prefix is last, it will override actual property, but both are the same anyway. The Future: Only actual property is supported, order doesn't matter.

More about

Answer 2

The idea is that once the rule is standardized that will overrule the other styles. Since the standard rule is on the bottom, it will be used instead of a vendor specific rule if the browser knows how. This allows for standardization while still supporting current implementations.

In your second example the vendor specific rules would override the standardized rule if the browser supports both. Vendor specific implementations may defer from the spec, and its better to be on the unified spec once its finalized to allow for easier cross browser changes.