Cutting down on vendor prefixes
Most web developers currently use vendor prefixes in CSS to enable certain features in some browsers. That’s fine, but sometimes I see code examples and prefix-adding tools that go a bit overboard with the support and add every possible prefix that has ever been in use (and sometimes even ones that were never used). I think there are a bunch of CSS properties that we can safely stop using vendor prefixes for, or at least considerably cut down on the number of prefixes.
In the examples that follow I note which prefixes, if any, that I currently use. I have only included CSS properties that are often used with several vendor prefixes but could very well lose all of them or just keep a single one.
You may be thinking “But no! You’re shutting out people using older versions of browser X!” No, this is not about shutting anyone out or not “supporting” a certain browser version. It is about using progressive enhancement to make your CSS smaller and easier to handle and maintain. We’re not talking about essential features here. If a browser doesn’t support an unprefixed property, well, there won’t be any rounded corners or shadows or gradients or whatever. The result will look the way it does in IE8, which currently often has a lot more users than, say, Firefox 3.6 or Chrome 9 or Safari for iOS 4 or some other old browser version that may need a vendor prefix.
As long as the entire layout doesn’t crash when something isn’t supported, that’s OK in general, given that at least the latest couple of versions of all major browsers will apply your CSS.
border-radius
No vendor prefixes.
.example {
border-radius:10px;
}
Current browser support for border-radius
.
box-shadow
No vendor prefixes.
.example {
box-shadow:0 0 5px rgba(0,0,0,0.5);
}
Current browser support for box-shadow
.
background-origin
, background-size
and background-clip
No vendor prefixes.
.example {
background-origin:content-box;
background-size:100% auto;
background-clip:content-box;
}
Current browser support for CSS3 Backgrounds.
Gradients
Gradients (linear-gradient
and radial-gradient
) are probably the properties where you have the most to save by cutting down on prefixes. I don’t go completely prefix-less here, but I only use the -webkit-
prefix (and not the old WebKit syntax).
So instead of something like this, which you get from many of the tools that add vendor prefixes:
.overkill-example {
background:#f9f9f9;
background:-moz-linear-gradient(top, #ffffff 0%, #f2f2f2 100%);
background:-webkit-gradient(linear, left top, left bottom, color-stop(0%,#ffffff), color-stop(100%,#f2f2f2));
background:-webkit-linear-gradient(top, #ffffff 0%, #f2f2f2 100%);
background:-o-linear-gradient(top, #ffffff 0%, #f2f2f2 100%);
background:-ms-linear-gradient(top, #ffffff 0%, #f2f2f2 100%);
background:linear-gradient(to bottom, #ffffff 0%, #f2f2f2 100%);
filter:progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#f2f2f2',GradientType=0 );
}
I would use this:
.example {
background:#f9f9f9;
background:-webkit-linear-gradient(top, #ffffff 0%, #f2f2f2 100%);
background:linear-gradient(to bottom, #ffffff 0%, #f2f2f2 100%);
}
That’s just one declaration extra. And Looking at the browser support for CSS gradients I think I’ll be dropping that too within a year or so.
calc()
I only use the -webkit-
prefix for this one.
.example {
background-position:100% 100%;
background-position:-webkit-calc(100% + 30px) -webkit-calc(100% + 16px);
background-position:calc(100% + 30px) calc(100% + 16px);
}
Note that you may want to use some caution with calc()
. If you use it on layout-affecting properties, make sure there is a fallback declaration for browsers that don’t support it so they don’t get a total trainwreck.
Current browser support for calc()
.
Transitions
For transitions I only use the -webkit-
prefix:
.example {
-webkit-transition:background-position 0.5s;
transition:background-position 0.5s;
}
As with gradients I don’t think it will be very long before I go completely prefix-less with transitions.
Current browser support for CSS Transitions.
Adapt to your scenario
The above are examples of how I currently deal with vendor prefixes for these CSS properties. If you, or your clients, have loads of users on old versions such as Firefox 3.6 or iOS 2.1, you may need to use more prefixes if progressively enhancing the visual appearance is not acceptable. Personally I have yet to receive a bug report related to omitting prefixes as described here, but then I do make an effort to explain progressive enhancement to the client early on.
- Previous post: Full-width justified vertically centered navbar
- Next post: Why I don’t use CSS preprocessors