How To Deal With Vendor Prefixes

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.

"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.

How To Deal With Vendor Prefixes is a post from CSS-Tricks

Source : internetwebsitedesign[dot]biz