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.
Anowar 21 Dec, 2010
visutech 21 Dec, 2010
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.
gigi becali 21 Dec, 2010
People have been crying about this for years now.
Vladimir Carrer 21 Dec, 2010
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 :)
Jitendra Vyas 21 Dec, 2010
Francesco 21 Dec, 2010
http://www.alistapart.com/articles/prefix-or-posthack/
I like prefixes, because without them, we would have so much less, today.
Peter Gasston 21 Dec, 2010
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.
Rob Crowther 21 Dec, 2010
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?
Kelvin 21 Dec, 2010
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;
}
Lars Gunther 21 Dec, 2010
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.
cssglobe 22 Dec, 2010
-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...
Peter Gasston 22 Dec, 2010
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.
gee 22 Dec, 2010
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
Red 22 Dec, 2010
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.
Patrick H. Lauke 22 Dec, 2010
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.
Jimmy 24 Dec, 2010
Gaurav Mishra 27 Dec, 2010