I’ve seen some grumbling on Twitter recently about browser prefixes being bad. They’re not. Browser prefixes let browser manufacturers introduce CSS features that have been proposed but that are not yet part of an official specification. Considering how many years that can take, it’s not a bad solution.

The grumbling isn’t about the introduction of draft declarations though, it’s about the browser prefixes. Some people—including some people at Opera and Microsoft—seem to think it would be a good idea to get rid of those prefixes altogether. Apparently the risk of future compatibility can be sacrificed at the altar of saving two lines of code.

As it stands right now I can, for example, round the corners of a box with the follow code:


/* This example uses a non-semantic class name. Get over it. */
div.rounded {
border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
}


One day, after the spec has been finalized, I’ll be able to do the same thing with just:


/* Still not semantic. Oi vey! */
div.rounded {
border-radius: 5px;
}


Of course, to support those damn legacy browsers I’ll probably stick to the three line version, as egregious as that is. Here’s the thing, though. If the spec does change and is then finalized after said change, Mozilla and WebKit can simply implement the final version correctly using “border-radius” and their legacy browsers will ignore that and use the browser specific versions (-moz and -webkit respectively). Meanwhile Opera will have to change how their existing implementation of border-radius works.

While it’s very unlikely that border-radius will change, it’s not impossible. And other bleeding-edge features of CSS3 stand a greater chance of changing before being finalized. A few lines of saved code are just not worth even the relatively minor risk of having to hack around different implementations of the same feature and the headaches that would case.

Box model anyone?