If you write CSS you almost surely need to be using vendor prefixes on some parts of the code you write in order to ensure the best browser support. Whether that is prefixed properties like -prefix-transform, prefixed at-rules like @-prefix-keyframes, or prefixes values like -prefix-linear-gradient, it’s a daily chore of CSS authors.
Not only is it part of our jobs, it’s an easy thing to screw up. I recently looked around at a bunch of big websites specifically looking for little nitpicky CSS3 errors and I was able to find one on any site I looked at.
So how do we author CSS so that we always are using the correct prefixes all the time?
Hand Author – Refer to CSS3Please
Hand authoring means the CSS that your sites uses in production (“live”) is the CSS file that you edit yourself in a text editor. Going this route means you’ll need to be including all the right vendor prefixes right in that authored file yourself. A bit tedious and error-prone for me liking, but likely scenario for most websites in the world.
If this is the case for you, your best bet is referencing an up-to-date resource like CSS3 please!. You can edit the values right on that site and copy-and-paste right into your own stylesheets.
If you do this, it means the onus is on you to keep things up to date. Prefixes aren’t as volatile they once were, but a look every few months is certainly warranted.
Hand Author – Don’t Prefix – Let -prefix-free do it client side
You still hand-author the CSS, but you only use the un-prefixed properties/values/at-rules. -prefix-free is a bit of JavaScript that runs, looks through all your CSS, and appends to the page new styles with the proper prefixes needed to make those styles work, if necessary.
This is holy war territory. It makes CSS files smaller! Yeah but it runs the risk of flashes of un-CSS3’d elements! It requires JavaScript for styles, crossing the streams! Yeah but it’s only 2k! It’s progressive enhancement at its finest since it will stop prefixing when browsers stop needing it!
You decide.
It’s also worth noting that jQuery’s .css() method will do some prefixing for you.
$("body").css({
// Will NOT prefix
"background": "linear-gradient(#ccc, #666)",
// Doesn't need to, so won't
"box-shadow": "inset 0 0 5px black",
// WILL prefix
"transform" : "rotate(5deg)"
});I’m not a fan of applying CSS through JavaScript usually, but good to know as there are always exceptions to rules.
Hand Author – Fix up with Prefixr
If you prefer not hand authoring the prefixes but ultimately your workflow deploys hand-authored CSS, you could run your CSS through Prefixr before deploying. It essentially parses your CSS, finds things that need prefixing, and does it for you.
It’s very smart in that you don’t have to have CSS that is specifically void of prefixes (like -prefix-free requires). For example if you just happen to be missing one of the required three prefixes, it will see that and only add the missing one.
It also has ways to be added to workflows via the command line or popular text areas.
Preprocess – Use mixins
One of the big reasons to use CSS preprocessors at all is because of the help with vendor prefixing.
If you use Sass, Compass or Bourbon have robust sets of CSS3 mixins for you.
If you use LESS, I have a set of them or you could look at this roundup comparing some others.
Hand Author – Don’t Prefix – Post Process with Autoprefixer
This is a really great way to do it. It’s all laid out in this article. Essentially you just forget about prefixing and this build step will add the prefixes for you according to the lastest and greatest information from CanIUse.
“Don’ts”
One mistake I sometimes see is that people just use all the major prefixes on every CSS3 property. It appears they have a generic mixin that they just put everything through that slaps on the prefixes. If you’ve seen something like -o-border-radius, that’s what I mean. That has never existed and never needs to go into your CSS.
Another mistake is letting CSS get stale. As I mentioned earlier, it’s worth a look at CSS older than a couple of months to make sure it’s up to snuff. If you see anything outdated on this site, please let me know and I’ll update it right away.
I think the best pre-processor tool to handle prefixes is NIB to use with Stylus. You don’t need a special syntax like those ugly Compass mixins. You write plain CSS and Stylus interpret it as a mixin and generate the right prefixes:
http://visionmedia.github.com/nib/
compass mixins aren’t that ugly, instead of:
-you do-
still very similar
It’s the same for bourbon :P
That’s interesting how NIB handles it. I could see arguments either way. I kinda like how simple that becomes. Just like “be smart for me, computer!” On the other hand, it’s nice to be explicit about when you want computer help and when you don’t. @include allows for that explicit-ness.
I reaaaally think it’s time to stop prefix stuff. An absolutely irrational useless thing
Awesome tools. It is really a painful experience and one often tends to forget some or other vendor prefix for styles. The Hand Author tool is my preferred way of doing things. I don’t have to worry anyway :)
I didnt think we even needed prefixes(browser specific hacks) any more after reading: https://css-tricks.com/do-we-need-box-shadow-prefixes/
I’m a big fan of Lea Verou’s prefixfree and its associated plugins. As long as things are generally coded to degrade gracefully. In a no JavaScript environment you’re probably also in an environment that isn’t going to recognize things like gradients and shadows applied with CSS anyway.
Prefixr looks like another great solution, but I haven’t used it as yet. Maybe I could use prefixfree while coding/using live reload, and then remove the link and run the CSS through Prefixr once coding is done.
What about
-ms-border-radius?Not a thing.
Thanks for this tips !
I’m a big fan of Prefixr, in particular because I do most of my html and css editing with TextMate and Chrome, and cross-browser testing after the fact. This way, I only worry about webkit prefixes while I’m coding, and have prefixr automate the rest when I’m ready to test in other browsers.
Hey,
Thanks for mentioning -prefix-free! One minor nitpick: -prefix-free doesn’t require that you use no prefixes. If you prefix something, it will leave it as is, without altering it in any way.
Thanks for clarifying!
For all:
If you want -prefix-free to help you prefix, you must leave things un-prefixed.
If you want to control your own prefixes, go for it, and -prefix-free won’t mess with them.
Does this mean that I could use both Compass and then -prefix-free to catch anything that I miss out?
At this stage, I think CSS3 must be regarded as an enhancement. I don’t like to hand off a design filled with prefixes – likely never to be updated – and I’m lazy and don’t want to keep updating sites I myself maintain. This is why I’m such a great fan of prefix-free. Thanks a bunch, Lea.
Before moving to SASS from LESS I wrote my own mixins or included some snippets I gathered online. Since there’s no Compass variant with LESS, you’re exposed to the ugliness and bulk the prefixes add to your CSS. I was conservative in my use because I was aware of what was really going on behind the scenes.
Now with Compass, I don’t have to think of the ugliness–It does the dirty work. It buys the hefty bags and digs the holes in the Nevada desert. I don’t ask questions anymore. But every once in a while I peek at the compiled CSS and shudder.
Ultimately, I chose the route of convenience and just let the preprocessor do it. It eliminates potential errors of hand-coding it myself, and at least Compass tries to implement only the prefixes that are truly necessary in real world circumstances and not just tack on every conceivable prefix, as your “Don’ts” concluded. You just have to make sure you keep Compass up-to-date.
One day (probably never) I’ll revisit this choice and once again choose convenience.
Excellent , as always!
What I don’t understand is why Sass and LESS need the use of mixins to add the prefixes. It would have been much better to be able to write standard CSS and have the required prefixes added automatically.
A note about CSS3Please: They dropped support for IE8 (which is still used by about 10% of the users), so keep that in mind.
That is interesting about dropping IE 8, thanks for noting.
All beware though: don’t base your decisions one some “10%” that you read somewhere. The only stats that you should ever base decisions on are stats that you’ve gathered from your own site.
Do you mean dropped support for CSS3Please to work in IE8, or dropped support for IE8 in the prefixes it outputs? Assuming its the former, who cares? I find it VERY hard to believe 10% of THEIR stats are IE8.
Re “don’ts” — I think you should add prefixes for potentially upcoming properties, i.e. when Opera didn’t support
border-radiusat all,-o-border-radiusdefinitely should have been included for future use.I definitely disagree there. That prefixed property never has existed and never will exist. Including it because you think it just might someday is a weird pre-optimization I can’t support.
I think, if you have a small project, that a simple mixin that prefix every CSS3 property with all vendors can be OK. Like the one used in inuit.css:
That just rubs me the wrong way, that’s all I can say.
Clearless is a pretty sweet LESS mixin library. It handles the prefix thing and lots of other cool stuff.
Yup! -prefix-free is awesome.
I use the Prefixr plugin for Sublime Text and it does a pretty good job of adding any prefixes I might have missed, or removing ones that are no longer needed. I’ve never really checked to see if it’s always up-to-date, but it does work as advertised.
I have to +1 Prefixr for ST2, I use it frequently, along with LESS mixins.
The code standard where I work – which sees a good deal of discussion and updating – requires all the major prefixes on any prefixed property. The rationale is that making sure all the bases are covered in the most consistent fashion possible and leaving it at that is the most efficient use of time, and that there is little benefit to spending time on which prefixes are currently required on any given property. Pragmatism rather than pre-optimization.
What is the benefit to spending that time? I think I must be missing something here.
Before I learned how to use Compass, I used CSS3 Please a lot. It wasn’t that bad because I used CSS3 mainly for minor enhancements that wouldn’t really be missed in lesser browsers. Now I rely on the Compass mixins after I got sick of maintaining my own. On the rare occasions I find myself writing vanilla CSS again, I use the Prefixr Sublime Text plugin to sort that out.
If I don’t use any vendor prefixes, box-shadow, border-radius etc work just fine for me in Firefox, Chrome, Safari, IE9. So why bother with them?
That’s another discussion I think, progressive enhancement is one way to go with it, but making a site prefix-cross-browser-compatible is another.
Great article, thanks Chris! After reading it, I wanted to give Prefixr a try, but cannot get it to work except for the default code that is shown there. Pity, because it sounds like an amazing tool
OK, I take that back, turned out that it doesn’t handle the top of my stylesheet. So first line needs to be an actual style.
Compass is best among all if you also want compatibility with Internet explorer. For example
https://gist.github.com/4410998
Prefix-free and Prefixer cannot do this
I think I will go with prefixr for now. Even though pre-processors might be an “easier way” to work. That said. If one tends to rely on “magic”, one might forget how to properly write css3… So my advice to beginners would be: write it all out as if it were standard css. The ones who know the tricks of the trade might as well make it easier for them through whatever workflow they want to go with… I just know that in 2 years time, a completely different approach might be best at that particular time.
Good read though ;) off to prefixr now to see how bad I really am css wise :d
Prefix-Free, for some reason, does not work when implemented in WordPress.
Something else going on there. I promise WordPress doesn’t care what JavaScript stuff you use in your theme.
first post very usefull i read today, NICE ONE BRO
un saludo
Diseño Web Colombia</ a>
Giuseppe Lidonnici