Vendor specific extensions: The Good, the Bad and the Ugly

Posted Oct 31, 2011 // 0 comments

The Good:

CSS3 is great fun! It can speed up our work process with simple syntax for creating awesome drop/text shadows, gradients, rounded corners, animations etc. It's a virtual wonderland for any web developer/designer for easily whip up visual elements that would normally take at least a few sprites, several hours of writing code and countless Advil when trying to get it all to work cross-browser. When a company wanted to experiment with the specification of a desired attribute, they would create an extension for the user base to 'beta' test it. This is great way to try things out.

With a simple declaration, we can have a drop shadow in no time:

box-shadow: 10px 10px 5px #888;

Or a subtle gradient:

background: linear-gradient(black, white);

We could call it a day if all the browsers met the desired specification from the W3C and implemented them accordingly. Unfortunately, this isn't the situation we currently live with and we're starting to see a growing trend that should be suppressed before it gets to out of control.

The bad:

Vendor specific extensions are the css hacks of today. We write out our style blocks in a way to cascade to style value that is relevant while still going down the line to the most standardized style. This is all the while going through an increasingly long list of vender specific extensions1. It certainly draws a close correlation to '* html', 'html>', or 'html>body' of only a few years ago, when we were trying to morph our code to be perfect for every browser. If you refer back to my previous post on progressive enhancement, we really should be pushing forward rather than coddling the dated and inefficient. Even with updates to the w3c validator to include css3, our style sheets still won't validate based on these extensions. With the correct amount of markup and careful consideration, no browser hack or browser extension should really be necessary.

  
-webkit-border-radius: 20px;  
-webkit-border-top-right-radius: 5px; 
-webkit-border-bottom-left-radius: 5px;  
-moz-border-radius: 20px;  
-moz-border-radius-topright: 5px;  
-moz-border-radius-bottomleft: 5px;  
border-radius: 20px; 
border-top-right-radius: 5px;  
border-bottom-left-radius: 5px;  

…is reminiscent of this:¹

  
padding: 10px;   
width: 200px;   
w\idth: 180px;   
height: 200px;   
heigh\t: 180px;  

..or

.classnameOrElement { 
  color /*\**/: blue\9 
}  
html>/**/body #id { 
  property: value; 
} 
.ie8only { 
  color /*\**/: #fff\9 
}

The Ugly:

This isn't even a full list of the extensions; we could include –o, -khtml, -ms and filter (depending on the desired effect you're looking for). Some of these browsers even go to the extent of supporting the same functionality but adding their own prefix to the effect. So in essence, we have some browsers supporting non-spec related functionality with their own prefix that all then do the same effect.

When will we just be able to write in 'border-radius:' or 'transition:' without declaring 5 other slightly similar lines of code to do the exact same things in another browser? It may be nit-picky to talk about supporting a few more lines of code to achieve a certain effect, but it's starting to feel like we are running away from web standards after we worked so hard to create standards from the overbearing rule of IE. If we work back towards standards, there is no reason to have an individualized browser extension. If it's good enough to be included in the w3c specification and gives your competition a run for their money, than a company shouldn't have to slap a browser specific extension on it.

1. www.alistapart.com/articles/prefix-or-posthack/