Home > Designing, Others > Vendor prefixes and web standards

Vendor prefixes and web standards

December 21st, 2010 Leave a comment Go to comments

When I started with the web development I was somewhat obsessed with web standards. The idea of having one set of rules or recommendations on how to develop a web page seemed like the only way to go in my professional life. The one thing that really annoyed me back then (besides various IE fixes and hacks) was browser inconsistent JavaScript support. I was in a place where I had to tweak and adjust every script I made and test it over and over again. Then this great thing came along so I am not worried about that anymore. The inconsistencies are still there, I just have a marvelous piece of code that does the worrying for me.

Most of the CSS properties however were cross browser supported all along. Sure, there are some misinterpretations and missing support for pseudo element here and there (especially with old mastodons browsers) but the situations wasn’t nearly as complicated as with JavaScript.

Then the web began to change. New technologies were introduced, new buzzes… Browser developers started to experiment in supporting cool CSS properties that not only could change the appearance of an element, they could also control the behavior.
As a web developer I couldn’t be more excited about these new properties. If nothing, it brought us choices. We don’t have to use them, but if we want to, we can.

Vendor prefixes

But there is one thing that is far from ideal…
In it’s original idea, standards should be a unique set of rules and coding recommendations applicable to all platforms, devices, browsers… Vendor prefixes couldn’t be further away from that. Applying a vendor prefix you target specific browser, so if you want to target another one, you either can’t or have to use another line of code with another “vendor prefixed” CSS property.

Take a look at this example

.box{
	-moz-box-shadow: 10px 10px 5px #000;
	-webkit-box-shadow: 10px 10px 5px #000;
	box-shadow: 10px 10px 5px #880008;
}

We all talk about IE hacks, how we hate it, how these are not complying to web standards, how they’re not valid… I am asking you, how is the example above different from these hacks?

I am aware that prefixes were used by browsers to try on new experimental properties. I salute that, without these great efforts we wouldn’t have progress. But do we have to keep the vendor prefixes for CSS properties that are not so experimental any more? Why don’t we have support for non prefixed properties now that some of the things are out of the experimental phase and more or less accepted?

Why are developers forced to write multiple lines of CSS for the same thing and when will it all be standardized?

In my opinion, vendor prefixes are unnecessary. If browsers want’s to experiment with new properties, what keeps them from doing so and use the “regular” naming conventions? It could even speed up the process of cross-browsers acceptance.

Let us know what do you think, I would really like to hear more thoughts on this one.

Categories: Designing, Others Tags:
  1. No comments yet.
  1. No trackbacks yet.