posted on:December 21, 2010

Vendor prefixes and web standards


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.

Enjoyed the article?

Then don't miss our next one! Subscribe to our RSS feed or share it with your friends.

DeliciousStumbleUpon RedditSubscribe

Comments (17 Comments)

  1. Anowar
    December 21, 2010

    You put up a good point, sometime we tend to have a blind spot to the stuff that we like and we cease to look upon it, I think, keeping a cycle of around 6 months on experimental stuff, browsers should dig out the exp tag and make it general, and yeah browser war will start, but w3c coming up to do will mitigate such issues, and i believe these non-IE guys are open, wont mind changing the name a/c to w3c

  2. visutech
    December 21, 2010

    It is a pain at the moment having to write the multiple lines, and I can see that for some more experimental areas of CSS3 that there is a reason for keeping the prefixes until w3c get CSS3 to a level that the browser producers are comfortable with. But come one - radius, shadow, RGBa - why aren't they just implemented without he prefix now? However - better to have a prefix than to have nothing at all - IE 8 and below... I was hoping that the w3c would now drop HTML'5' and CSS'3' numbering and just say - there is HTML and CSS. These specs will be updated on a quarterly basis. Those attributes that can be agreed on get implemented ON A REGULAR BASIS.

  3. gigi becali
    December 21, 2010

    Welcome to 2010 Alen. People have been crying about this for years now.

  4. Vladimir Carrer
    December 21, 2010

    I absolutely agree , Vendor prefixes are in absolute contradiction to the web standards. I suggested possible alternative, use of -css3 prefix for all new experiments, so we don't have to have(-moz, -webkit, -o and others) just -css3. I wrote more on my blog http://www.vcarrer.com/2010/05/css-vendor-prefixes-can-we-all-get.html. Unfortunately there is no easy solution for this problem. Good news is people usually have lattes version on their not IE browser so we don't need to wait 10 years to people to move from Firefox 3.0 to Firefox 3.5 or from Safari 4 to Safari 5 so there is hope :)

  5. Jitendra Vyas
    December 21, 2010

    I've asked same question on Stackoverflow 7-8 month ago http://stackoverflow.com/questions/2437502/why-do-browser-vendors-make-their-own-css-properties and got some answers

  6. Francesco
    December 21, 2010

    I assume you're familiar with this article by Eric Meyer? http://www.alistapart.com/articles/prefix-or-posthack/ I like prefixes, because without them, we would have so much less, today.

  7. Peter Gasston
    December 21, 2010

    I see this question crop up with depressing regularity. Using browser prefixes is a vital step in the development of cross-browser standards; to see why this is necessary, you only have to look at border-radius, which was implemented differently in WebKit & Mozilla until recently. If they'd both used the same prefix, you would have got different results in the two browsers, with no way to work around it. Once all of the browsers have a standard implementation, they begin to drop the prefix - as has happened now with border-radius. Early next year, all major browsers will support border-radius without a prefix. But the prefixes were absolutely necessary to get to this stage. Read Eric Meyer's article for a more in-depth explanation of that. A momentary inconvenience to us as developers is a price worth paying for web standards, and whether you like it or not they are here to stay.

  8. Rob Crowther
    December 21, 2010

    > But do we have to keep the vendor prefixes for CSS properties that are not so experimental any more? No, but can you give a more reasonable definition of 'not so experimental any more' than 'when the spec reaches CR status' which is what we currently have?

  9. Kelvin
    December 21, 2010

    Vendor prefixes are essential for the progression of browser development. But they're a PITA for developers. I'd advocate a way for developers to inform a browser that it trusts a particular browser's implementation of as feature/property. E.g. @browser { -moz-box-shadow: trust; }

  10. Lars Gunther
    December 21, 2010

    > But do we have to keep the vendor prefixes for CSS properties that are not so experimental any more? Let me add to weight to the lst comment by Rob Crowther. "Not so experimental" is terribly vague. There are always edge cases - and in fact very non-edgy cases as well - that many developers don't know about. How should a browser treat rounded corners where on side is double and the other is single? How should browsers treat multiple background images when one fails to load? These are examples of questions that will have very drastic effects on ones design. And they are examples of questions that did take some time to resolve between vendors inside the CSS WG. Thus we have situation where there is a definitive line to cross, when something is considered stable. It is called Candidate Recommendation. That system could perhaps be improved by marking up some PARTS of a pre-CR draft as "mature enough" to implement, even while the complete spec is not CR worthy. BTW, in my dev work, typing is like 2 % of the total time I spend on a project. Dropping prefixes would reduce my work load by 0.1 % - probably less.

  11. cssglobe
    December 22, 2010

    I am talking about standardizing things. i.e. border radius property was announced in 2005. I doubt that it is still being developed (although I believe we still have background bleeds with webkit). Entire generation of developers were "forced" to use vendor prefixes for properties like that. To make things even more "non-standard", currently we have situations like this: -moz-border-radius-bottomright -webkit-border-bottom-right-radius And on top of that, there are differences in property values support: https://developer.mozilla.org/en/css/-moz-border-radius. Although this particular property will be included in Safari 5 and Firefox 4, we still have differences, so the vendor prefixes didn't serve the purpose here...

  12. Peter Gasston
    December 22, 2010

    First of all, no-one is 'forced' to use browser prefixes; they are experimental, and probably shouldn't be used by most people, as they are subject to change in future. Also, the border-radius property has indeed been changed since 2005; the shorthand property was changed in 2008 to add the dividing slash / for unequal radii. Before this change, without prefixed properties your rounded corners would display completely differently in WebKit & Firefox. And border-radius is only one property; imagine how many changes are introduced across four major browser engines on specifications which still aren't finished. As an example, what would the non-prefixed property of gradient/linear-gradient/radial-gradient look like? All you're arguing in favour of is your own impatience. Prefixes are required in order to make standards, and if you're complaining about taking a few minutes extra to use browser prefixes, try thinking about the extra time required to work around them; compare writing three border-radius properties with creating rounded corner graphics and adding extra markup.

  13. gee
    December 22, 2010

    Hi sir: i think you need it. please have a look! iphone web template bundle – learn more here: http://iconnice.com/bundle.html 23 Christmas Set bundle http://iconnice.com/html-graphic/graphic9.html

  14. Red
    December 22, 2010

    Webkit already dropped prefix for border radius, so you can use border-radius now instead of -webkit-border-radius. Soon, I expect other properties prefixes will be dropped. IE hacks like fixing "double margin" etc will be forever as nobody works to improve IE6 or IE7.

  15. Patrick H. Lauke
    December 22, 2010

    "I am talking about standardizing things. i.e. border radius property was announced in 2005." the spec is indeed now stable enough here (noting peter's comment above about a further change made in 2008). browsers are now (some faster, some slower) implementing it without prefix. in opera, you can already just write border-radius (full disclosure: i work for opera as web evangelist), as the spec is not expected to change anymore. and again, as peter pointed out, this simple example is exactly why vendor prefixes are necessary: if all browsers simply implemented border-radius back in 2005, and then the spec changes, you'd have situations where older and never versions of the same browser behaved differently when encountering the unequal radii feature...that would be more of a PITA than having to use prefixes for the time being.

  16. Jimmy
    December 24, 2010

    I think Peter Gasston said it all - vendor prefixes are experimental. If you don't want to use them then don't. Simple as that - all of the reasons that you quote go against using these CSS properties, they are not arguments agaist having vendor-prefixed properties available prior to being standardised.

  17. Gaurav Mishra
    December 27, 2010

    Vendor prefixes should not be used. But to keep the cutting edge some designers don't want to ignore it. Am i right ? : )

Sorry, the comment form is closed at this time.