.o0( Why shosuld I use Browser Prefixes in CSS ?)

Browsers don't ya just love em? We wait with baited breath for each new iteration of our favourite window onto the internet and with each new version we devs get new toys to play with. Now the Browser writers (well all of them except the ****wits that write IE) like the new stuff that is coming down the tuvbes from the W3C however there are things that are no yet at Cadidate Recommentation status, so they add a browser specific prefix in front of the property so that the particular rendering engine can process it. For example the -mox-border-radius is the Mozilla (Firefox, Camino and Flock) version of the border-radius  property.

The prefixes are:

1. -khtml- for Konqueror rendering engine KHTML
2. -ms- for IE's rendering engine Trident
3. -moz- for Firefox,Camino and Flock's engine Mozilla
4. -o- for Opera, Opera Mobile, Opera Mini, Nintendo Wii engine Presto
5.  -webkit- Safari, Mobile Safari, Chrome,Android engine webkit.

So why do these boyos exist? Well it allows the rendering engineers to "play" with new properties and values before they are finalised which is a good way for them to be tested in the wild and then corrected and tweaked as required. If they were just to jump straight in they would then be locked into that behaviour for ever. Devs like me would start making curvey corners and using partially opaque PNGs and quite rightly expect that when the browsers updated that particular behaviour would continue to work in a standard way.from that point onward. If the browser changed the standard property for whatever reason, buggy or a W3C spec change then lots of websites could potentially stop working as expected ... so they use the prefixes to get around this.  Have a look at Prefix or Posthack by Eric Meyer for an example of this actually happening.

CSS has long been a country full of "hacks" and kludges that rely on bugs in rendering engines most completely unrelated to the property you want to "hack" which are used to get the browser to do what you want it to do.


So you can use both the standard unrefixed property in your CSS and use the prefixed version as well, this means that as the property becomes a standard an impliemented in the same way over all the browsers your precious web pages will not break. It should be noted that IE9's prefixes are a bit "odd" at the minute for lots of properties they decided to jump straight into the standard and hope that the W3C doesn't change the spec!

div {
                  -moz-transform: rotate(45deg);
                  -o-transform: rotate(45deg);
                  -webkit-transform: rotate(45deg);
                  transform: rotate(45deg)
}

In the code aboveI am rotating a [DIV] element thru 45 degrees and I am covering the main browsers (inc IE9) However .. all this repitition will lead to large css files. It really would be so much nicer to have one single entry and have done with it. Well there is a way around this using a CSS pre-processor. SASS is one and LESS and eCSSTender to name 3. However by hiding prefixes with pre-processors devs may forget that they are using "experimental" properties that are likely to change when they are infact nothing of the kind. Also the Pre-Processor comes with a browser overhead and process overhead on the user's PC which becomes more noticeable on complex pages,

As time progresses you can remove the browser prefixs from your CSS, which is MUCH easier than "unhacking" css using the older hacks that relied on browser bugs.

A minor annoyance of using prefixes is that they do not validate and in DDE this can be a pain and can hide real errors in your CSS. to get around this I generally have two CSS files.. one with the pristine Standard CSS and one with the prefixes. There is an extra HTTP request hit here, but it does make debugging easier during testing.

So there you have it Prefixes .. next time I will have a think about coping with browsers that don't support CSS3