Florian – if you follow the cascading method, the final declaration, below browser-specific implementations, would be the standardized syntax. Therefore, when a recommendation is finalized and browsers support it as it should, it will already show up properly. If you’re interested in saving a few kB of space you can go back and delete the old code, but it’s silly. And then the older browsers won’t be able to see it.
Eric – excellent article! Thanks for the clear explanation. It’s definitely a great way to continue moving forward. Tedious, but at least it will create a better form of communication.
Imagine we could have done things like ie6-margin-right instead of the star hack! (I know, it would really be -ms, not version-specific!)
with one thing that actually spoiled the whole message of it.
Netscape supported box sizing model in NN4, IE4 copied this functionality. In 1997 2 browsers with 98% of market share supported either box sizing model or no model at all (previous versions of NN and IE). So there was solution, in 1998 W3C should recommend box sizing model instead of content sizing model and we would have not spent decade in nightmare.
But to the point of this article. Any unification (e.g. -beta) would solve only one problem: more coding, but introduced new one: inconsistence in implementation yet again. So no solution at all.
First and foremost, this article was spot on Eric – it’s much better for designers / developers to have the ability to specific browser specific behavior than be forced to program in hacks.
I have once concern though. The notion of browser makers proliferating prefixes presumes that they want to be compliant and interoperable. So what happens when a browser maker stops caring about standards compliance and interoperability?
Consider IE’s non-standard rendering engine. Microsoft had a huge obligation to their existing customers, especially those with support contracts. Customers had written a lot of software that depended on IE’s non-compliance, and they were paying Microsoft a lot to keep that software running smoothly. The fact that IE wasn’t compliant just wasn’t an issue from their perspective. (Their overwhelming control of the browser market certainly didn’t help the issue – since so many people were using IE, designers had to take it into account regardless.)
This isn’t just an issue for companies who have a lot of existing customers to support, it’s also an issue for those who are extremely innovative, like Apple. Browsers (and plugins) have always lead W3C in terms of the technology (ie, video and rounded corners), so it’s not hard to imagine that they would come up with something really innovative, gather a lot of support around it, and then refuse to implement the spec because their own implementation provides a better experience for people using their other software and / or devices.
In the long run, W3C is like the old man of the Internet. Since it’s got no commercial interest and no competition, it can spend the time to reflect and garner a perspective about the way things should be. Unfortunately, it’s really got no power to compel people to listen – the best it can do is try to persuade.
Browser makers on the other hand are in the exact opposite boat – they’re surrounded on all sides by those who would seek to destroy them and (generally) investors demanding a return. They have to do whatever it takes to stay afloat, including walking away from the standard when it doesn’t suit their needs.
I disagree completely with this article.. it is absurd.. imagine FF, IE, Opera, Safari etc all having their OWN -moz, -ie, -op etc codes.. we would then have to repeat same thing n times to get them to work in n browsers…
instead I don’t see why if a browser gets something wrong, they can issue a WARNING a month or two prior saying they got xyz wrong (ie IE could have said they got box model wrong) and post a detailed explanation and give a time limit of TWO months or whatever is appropriate (hell even 6 months – 1 year) for web masters to CHANGE…
Copy & paste the code below to embed this comment.
egrivel
Although I agree with most of the article, and would like the idea of browsers to get certified as some point, I’m not sure if that is really practical. Instead, doesn’t the current system work well enough—let the community feedback do the work?
The purpose of a prefix is to allow the STANDARD to change while it moves from first proposal to an agreed-upon standard. The purpose of a prefix is not to test the browser’s implementation: that is what the beta testing phase is about. It doesn’t make sense to me to mix the two.
So when there is a new feature accepted as a standard, browsers should be allowed to implement it, and have their beta testers verify that their implementation actually is the correct one. Web site developers can either use browser-specific implementations of a draft feature using the prefixes, or wait for the standard and only use that.
Of course, this would all assume that the standards themselves are written clearly so that people will recognize a correct implementation when they see it. However, that isn’t really very different from expecting a standards committee to recognize a correct implementation when they see it (by having them certify implementations).
Honestly, we all hate the work involved in remembering to make that darn curve work in multiple browsers but in the end if it makes the site look good. It it worth it?
As far as doing more markup vs. more css. I’d take more CSS any day over bloating the code.
As far as an alternative (and keep in mind I’m saying alternative and not better way) would be to use graphics for your gradient. Yes it’s better to have everything coded but with a graphic you’re almost guaranteed that it’ll view the way you want if your divs are correct. And if you optimize the graphics they can be real small and still look sharp.
I think that the W3C should change the rules regarding how vendor prefixes are used, prefixes should take precedence over unprefixed rules in order to allow a sort of property name specificity. An outline of my idea: http://samshull.blogspot.com/2010/07/prefix-or-posthack-or-both.html
I personally don’t mind the concept of browser prefixes. However when thinking objectively about them, the do feel basically like sophisticated hacks. It’s a shorter and cleaner way of browser sniffing (and it works better). But like I said, I don’t mind writing them.
However, I do think that a unified prefix could be beneficial for everyone involved. First and foremost, it reduces file size, which means faster load times, which Matt Cutts has recently mentioned is becoming a factor. Secondly, while we all would love to be our clients’ web designers from now until the day the internet is turned off, it doesn’t always happen that way. I have a handful of clients who I have not heard from since I received final payment from them. In these instances, while I agree with you Eric that vendor prefix usage will dwindle overtime, this will only occur if we as the designer are still involved in the site. If we are no longer in the loop, the client is stuck with extra code that is only slowing down their load times.
Its not about browsers fixing themselves in a given time span. Its about users. Any time a new browser is released, users start using it—and they don’t stop using it.
I would much prefer prefixes over exploiting parser differences.
Insightful article! I liked your observations about the experimental nature of working with CSS3 in its early stages—that designers should expect various browsers’ implementations of CSS3 properties might change over time—as well as the careful ordering of rules, from vendor-specific to general.
Here are my thoughts on how the current system could be modified for the benefit of CSS designers and developers:
1) Allow the use of vendor-specific prefixes to target browsers at ANY stage of CSS implementation.
Browser differences are invevitable and, from time to time, need to be accomodated. We already have conditional comments for IE; why aren’t we able to target other browsers when necessary? Adding a vendor-specific prefix to a rule and placing it AFTER a general (or conflicting) rule could accomplish this quickly and easily.
line-height: 1.1em;
-o-line-height: 1.2em;
2) Create a -beta prefix (maybe just a hyphen by itself?) to target new properties, with the option to override via vendor-specific prefixes.
This approach could offer the best of both worlds: simplicity, with an option for specificity. When differences between implementations of a new CSS3 property are negligible, designers could rely on a single rule:
-beta-box-shadow: 0 3px 10px #aaa;
Or even simpler:
-box-shadow: 0 3px 10px #aaa;
When implementations are not so compatible, vendor-specific prefixes could be invoked:
background: -moz-linear-gradient(top, #223344, #6c7782) repeat-x;
background: -webkit-gradient(linear, left top, left bottom, from(#223344), to(#6c7782)) repeat-x;
An obvious question regarding a broader application of vendor-specific prefixes (allowing them to denote both experimental and standardized versions of a property) is: Could this cause a design to fail once the specs/implementations change? Your article seems to respond by suggesting that such changes are to be expected regardless. Moreover, I suspect that careful placement of a more general rule would distinguish one case from other, and render the first case harmless:
a)
-ms-text-curl: minor;
text-curl: minor;
b)
text-curl: minor;
-ms-text-curl: minor;
On the other hand, perhaps notation should more accurately reflect intent? In that case, vendor-specific prefixes (e.g., -ms) would best be used to target browsers, a beta prefix to target experimental CSS properties, and a combination of the two to target browser-specific, experimental implementations:
Copy & paste the code below to embed this comment.
stubear
One major flaw in all this is the assumption that once a new browser is available, everyone will flock to and download it. I believe the persistence of IE6 is a testament to what will likely happen. A less extreme example can be found by digging through your analytics. I know I still see plenty of early builds of Firefox that have spotty prefix support at best.
So, what’s the problem you might ask? How long do we leave the prefixes in our code? You talk as if one day in the near future everything will be all green fields and summer time, skies the purest blue, and web developers all frolicking as if Pan himself. I think it’s more likely that these prefixes are a more permanent feature of our CSS and thus less of a temporary fix to a problem, the working group not working fast enough.
Interestingly enough, I see Safari being updated in my analytics at a much faster pace then anything else and that’s because Apple throws Safari updates in with OS software updates. Oh, if another vendor in Washington State cold get away with the same thing without getting a bunch of geeks panties all in a bunch, what a world that would be. We might be closer to your green fields and summer time, blue skies and frolicking.
One problem with the vendor prefixes occurs when you access prefixed properties through JavaScript.
In every browser, a dash indicates that the next letter of the property name in JavaScript is a Capital Letter. So “border-radius” becomes “borderRadius” in JavaScript. The same is true for vendor prefixes. “-moz-transform” becomes “MozTransform”. That makes it pretty easy to create a name translation algorithm.
…if it weren’t for IE. IE does this differently. I discuss this at “my blog”:http://blog.attrakt.se/2010/11/browser-prefixes-in-ie-are-different.html
Copy & paste the code below to embed this comment.
Francisc
I agree prefixes are better than all other options when different browsers use the same property differently.
However, they are better because they are the lesser evil, which doesn’t make them better in the true sense of the word.
There should be homogenous syntax in all browsers. Vendors are to blame here: it’s not that much of a complication to talk with eachother and do things the same way. Declaring gradients with positions first and colours later and vice-versa isn’t something that is complicated to unify. It’s not like vendors have to change the whole rendering engine, just how they parse parameters p1=position, p2=colour. EASY. They just have to discuss and think about what the Open Web is all about, because I can tell you it’s not about petty rivalry. They aren’t suppose to be first to the finish line to “sell” the product first. No one will “buy” Mozilla because THEY have rounded corners nailed and others don’t yet. It’s a different market.
As for “you can drop the prefix once all is good” part, that will never work. You can’t trust people to always have the latest version of a browser. Just think of the high percentage IE6 still owns after what, 10 years or so?
However, this WAS a very good article. So thank you.
Copy & paste the code below to embed this comment.
gorn
I have very simple idea. If any browser implementing new property would parse prefixed version as well as the non-prefixed version from the very beginning, than we could just stop to use the prefixed properties until we see that anything brakes. If for example new property text-curl is proposed then we just use
text-curl: minor;
in our stylesheets and wait what happens. When browsers start to implement the behavior properly, than we do not have to do anything. If for example IE implements it with bugs, then as soon as we read about it in designers blogs we just use the prefix to correct it by saying
text-curl: minor;
-ie-text-curl: normal;
Yes, I am suggesting to put the prefixed version after the normal one, so we can override the behaviour for buggy browser.
Before you start to criticize the idea, think about it – in fact this is exactly what we are already doing by automatically use the four different prefixes for any new property introduced. By writing
we just say “I hope that everyone is implementing the property correctly” and only if/after we find out a bug we are correcting the css. So why not use the same approach with much less hassle?
58 Reader Comments
Back to the ArticleTeviH
Florian – if you follow the cascading method, the final declaration, below browser-specific implementations, would be the standardized syntax. Therefore, when a recommendation is finalized and browsers support it as it should, it will already show up properly. If you’re interested in saving a few kB of space you can go back and delete the old code, but it’s silly. And then the older browsers won’t be able to see it.
Eric – excellent article! Thanks for the clear explanation. It’s definitely a great way to continue moving forward. Tedious, but at least it will create a better form of communication.
Imagine we could have done things like
ie6-margin-right instead of the star hack! (I know, it would really be -ms, not version-specific!)Scott Fennell
I think a lot of the craziness of multiple prefixes can be greatly reduced by saving your stylesheet as a php file, and declaring a variable like so:
$border_radius_5 = “border-radius=5px; -moz-border-radius=5px; -webkit-border-radius=5px;”;
Scott Fennell
(It’s early for me, pardon the equals signs instead of colons).
Bauglir
with one thing that actually spoiled the whole message of it.
Netscape supported box sizing model in NN4, IE4 copied this functionality. In 1997 2 browsers with 98% of market share supported either box sizing model or no model at all (previous versions of NN and IE). So there was solution, in 1998 W3C should recommend box sizing model instead of content sizing model and we would have not spent decade in nightmare.
But to the point of this article. Any unification (e.g. -beta) would solve only one problem: more coding, but introduced new one: inconsistence in implementation yet again. So no solution at all.
David Rivers
Although I am a fan of this site and also of Eric Meyer’s work (I use his CSS reset regularly), calling him a “King of CSS” is a tad sensational, no?
zach at longtail
First and foremost, this article was spot on Eric – it’s much better for designers / developers to have the ability to specific browser specific behavior than be forced to program in hacks.
I have once concern though. The notion of browser makers proliferating prefixes presumes that they want to be compliant and interoperable. So what happens when a browser maker stops caring about standards compliance and interoperability?
Consider IE’s non-standard rendering engine. Microsoft had a huge obligation to their existing customers, especially those with support contracts. Customers had written a lot of software that depended on IE’s non-compliance, and they were paying Microsoft a lot to keep that software running smoothly. The fact that IE wasn’t compliant just wasn’t an issue from their perspective. (Their overwhelming control of the browser market certainly didn’t help the issue – since so many people were using IE, designers had to take it into account regardless.)
This isn’t just an issue for companies who have a lot of existing customers to support, it’s also an issue for those who are extremely innovative, like Apple. Browsers (and plugins) have always lead W3C in terms of the technology (ie, video and rounded corners), so it’s not hard to imagine that they would come up with something really innovative, gather a lot of support around it, and then refuse to implement the spec because their own implementation provides a better experience for people using their other software and / or devices.
In the long run, W3C is like the old man of the Internet. Since it’s got no commercial interest and no competition, it can spend the time to reflect and garner a perspective about the way things should be. Unfortunately, it’s really got no power to compel people to listen – the best it can do is try to persuade.
Browser makers on the other hand are in the exact opposite boat – they’re surrounded on all sides by those who would seek to destroy them and (generally) investors demanding a return. They have to do whatever it takes to stay afloat, including walking away from the standard when it doesn’t suit their needs.
shez
I disagree completely with this article.. it is absurd.. imagine FF, IE, Opera, Safari etc all having their OWN -moz, -ie, -op etc codes.. we would then have to repeat same thing n times to get them to work in n browsers…
instead I don’t see why if a browser gets something wrong, they can issue a WARNING a month or two prior saying they got xyz wrong (ie IE could have said they got box model wrong) and post a detailed explanation and give a time limit of TWO months or whatever is appropriate (hell even 6 months – 1 year) for web masters to CHANGE…
egrivel
Although I agree with most of the article, and would like the idea of browsers to get certified as some point, I’m not sure if that is really practical. Instead, doesn’t the current system work well enough—let the community feedback do the work?
The purpose of a prefix is to allow the STANDARD to change while it moves from first proposal to an agreed-upon standard. The purpose of a prefix is not to test the browser’s implementation: that is what the beta testing phase is about. It doesn’t make sense to me to mix the two.
So when there is a new feature accepted as a standard, browsers should be allowed to implement it, and have their beta testers verify that their implementation actually is the correct one. Web site developers can either use browser-specific implementations of a draft feature using the prefixes, or wait for the standard and only use that.
Of course, this would all assume that the standards themselves are written clearly so that people will recognize a correct implementation when they see it. However, that isn’t really very different from expecting a standards committee to recognize a correct implementation when they see it (by having them certify implementations).
goldsteinmedia
Honestly, we all hate the work involved in remembering to make that darn curve work in multiple browsers but in the end if it makes the site look good. It it worth it?
As far as doing more markup vs. more css. I’d take more CSS any day over bloating the code.
As far as an alternative (and keep in mind I’m saying alternative and not better way) would be to use graphics for your gradient. Yes it’s better to have everything coded but with a graphic you’re almost guaranteed that it’ll view the way you want if your divs are correct. And if you optimize the graphics they can be real small and still look sharp.
Just my two cents.
brickysam26
I think that the W3C should change the rules regarding how vendor prefixes are used, prefixes should take precedence over unprefixed rules in order to allow a sort of property name specificity. An outline of my idea: http://samshull.blogspot.com/2010/07/prefix-or-posthack-or-both.html
desertwebdesigns
I personally don’t mind the concept of browser prefixes. However when thinking objectively about them, the do feel basically like sophisticated hacks. It’s a shorter and cleaner way of browser sniffing (and it works better). But like I said, I don’t mind writing them.
However, I do think that a unified prefix could be beneficial for everyone involved. First and foremost, it reduces file size, which means faster load times, which Matt Cutts has recently mentioned is becoming a factor. Secondly, while we all would love to be our clients’ web designers from now until the day the internet is turned off, it doesn’t always happen that way. I have a handful of clients who I have not heard from since I received final payment from them. In these instances, while I agree with you Eric that vendor prefix usage will dwindle overtime, this will only occur if we as the designer are still involved in the site. If we are no longer in the loop, the client is stuck with extra code that is only slowing down their load times.
designvibe
More CSS is better than more markup. Reduces traffic and keeps presentational stuff out of your HTML.
Interesting read, thanks!
Stargazer
shez,
Its not about browsers fixing themselves in a given time span. Its about users. Any time a new browser is released, users start using it—and they don’t stop using it.
I would much prefer prefixes over exploiting parser differences.
Doug Downing
Insightful article! I liked your observations about the experimental nature of working with CSS3 in its early stages—that designers should expect various browsers’ implementations of CSS3 properties might change over time—as well as the careful ordering of rules, from vendor-specific to general.
Here are my thoughts on how the current system could be modified for the benefit of CSS designers and developers:
1) Allow the use of vendor-specific prefixes to target browsers at ANY stage of CSS implementation.
Browser differences are invevitable and, from time to time, need to be accomodated. We already have conditional comments for IE; why aren’t we able to target other browsers when necessary? Adding a vendor-specific prefix to a rule and placing it AFTER a general (or conflicting) rule could accomplish this quickly and easily.
line-height: 1.1em;
-o-line-height: 1.2em;
2) Create a -beta prefix (maybe just a hyphen by itself?) to target new properties, with the option to override via vendor-specific prefixes.
This approach could offer the best of both worlds: simplicity, with an option for specificity. When differences between implementations of a new CSS3 property are negligible, designers could rely on a single rule:
-beta-box-shadow: 0 3px 10px #aaa;
Or even simpler:
-box-shadow: 0 3px 10px #aaa;
When implementations are not so compatible, vendor-specific prefixes could be invoked:
background: -moz-linear-gradient(top, #223344, #6c7782) repeat-x;
background: -webkit-gradient(linear, left top, left bottom, from(#223344), to(#6c7782)) repeat-x;
An obvious question regarding a broader application of vendor-specific prefixes (allowing them to denote both experimental and standardized versions of a property) is: Could this cause a design to fail once the specs/implementations change? Your article seems to respond by suggesting that such changes are to be expected regardless. Moreover, I suspect that careful placement of a more general rule would distinguish one case from other, and render the first case harmless:
a)
-ms-text-curl: minor;
text-curl: minor;
b)
text-curl: minor;
-ms-text-curl: minor;
On the other hand, perhaps notation should more accurately reflect intent? In that case, vendor-specific prefixes (e.g., -ms) would best be used to target browsers, a beta prefix to target experimental CSS properties, and a combination of the two to target browser-specific, experimental implementations:
-ms-beta-text-curl: minor;
Much ado over a minor text-curl, huh?
stubear
One major flaw in all this is the assumption that once a new browser is available, everyone will flock to and download it. I believe the persistence of IE6 is a testament to what will likely happen. A less extreme example can be found by digging through your analytics. I know I still see plenty of early builds of Firefox that have spotty prefix support at best.
So, what’s the problem you might ask? How long do we leave the prefixes in our code? You talk as if one day in the near future everything will be all green fields and summer time, skies the purest blue, and web developers all frolicking as if Pan himself. I think it’s more likely that these prefixes are a more permanent feature of our CSS and thus less of a temporary fix to a problem, the working group not working fast enough.
Interestingly enough, I see Safari being updated in my analytics at a much faster pace then anything else and that’s because Apple throws Safari updates in with OS software updates. Oh, if another vendor in Washington State cold get away with the same thing without getting a bunch of geeks panties all in a bunch, what a world that would be. We might be closer to your green fields and summer time, blue skies and frolicking.
atornblad
One problem with the vendor prefixes occurs when you access prefixed properties through JavaScript.
In every browser, a dash indicates that the next letter of the property name in JavaScript is a Capital Letter. So “border-radius” becomes “borderRadius” in JavaScript. The same is true for vendor prefixes. “-moz-transform” becomes “MozTransform”. That makes it pretty easy to create a name translation algorithm.
…if it weren’t for IE. IE does this differently. I discuss this at “my blog”:http://blog.attrakt.se/2010/11/browser-prefixes-in-ie-are-different.html
Francisc
I agree prefixes are better than all other options when different browsers use the same property differently.
However, they are better because they are the lesser evil, which doesn’t make them better in the true sense of the word.
There should be homogenous syntax in all browsers. Vendors are to blame here: it’s not that much of a complication to talk with eachother and do things the same way. Declaring gradients with positions first and colours later and vice-versa isn’t something that is complicated to unify. It’s not like vendors have to change the whole rendering engine, just how they parse parameters p1=position, p2=colour. EASY. They just have to discuss and think about what the Open Web is all about, because I can tell you it’s not about petty rivalry. They aren’t suppose to be first to the finish line to “sell” the product first. No one will “buy” Mozilla because THEY have rounded corners nailed and others don’t yet. It’s a different market.
As for “you can drop the prefix once all is good” part, that will never work. You can’t trust people to always have the latest version of a browser. Just think of the high percentage IE6 still owns after what, 10 years or so?
However, this WAS a very good article. So thank you.
Stick a fork in me, I’m done.
gorn
I have very simple idea. If any browser implementing new property would parse prefixed version as well as the non-prefixed version from the very beginning, than we could just stop to use the prefixed properties until we see that anything brakes. If for example new property text-curl is proposed then we just use
text-curl: minor;
in our stylesheets and wait what happens. When browsers start to implement the behavior properly, than we do not have to do anything. If for example IE implements it with bugs, then as soon as we read about it in designers blogs we just use the prefix to correct it by saying
text-curl: minor;
-ie-text-curl: normal;
Yes, I am suggesting to put the prefixed version after the normal one, so we can override the behaviour for buggy browser.
Before you start to criticize the idea, think about it – in fact this is exactly what we are already doing by automatically use the four different prefixes for any new property introduced. By writing
-ie-text-curl: minor;
-moz-text-curl: minor;
-webkit-text-curl: minor;
-o-text-curl: minor;
text-curl: minor;
we just say “I hope that everyone is implementing the property correctly” and only if/after we find out a bug we are correcting the css. So why not use the same approach with much less hassle?