Straight forward question by Jay Hughes:
@chriscoyier Do we need -moz and -webkit prefixes anymore on popular items such as border radius and box shadow? Is there a post abt this?
— Jay Hughes (@graphicsjay) November 28, 2012
I didn’t specifically have a post about this, so let’s do it!
Short Answer
Specifically for box-shadow and border-radius, probably not.
You only need them if:
- It’s a rare situation where the square-corner or no-shadow fallback hurts the experience.
- And your site has significant traffic of Firefox 3.6-, Safari 4-, iOS 3.2-, or Android 2.3-
Long Answer
Let’s explore a bit deeper. First, you can see exactly what browsers support what features at Can I use….
Second, you should only make decisions about feature support based on statistics from your own site and nothing else.
border-radius
Firefox 3.6- needs -moz-. From 4 up, unprefixed is fine. On this site, that’s 0.3% of the 30% or so that use Firefox.
Safari 4- needs -webkit-. That’s even smaller for this site. 0.1% of the 10% or so using Safari.
iOS 3.x needs -webkit- too, which means an iPhone 3GS or iPad 1 that have never been upgraded, which is the smallest number yet.
Again, it’s your sites stats that matter, but I’d guess most sites are well under 1% for all this combined.
Not to mention, a non-rendering border-radius is the poster child for “who cares” fallbacks.
box-shadow
Box shadow is similar but slightly more strict. Exactly the same for Firefox and iOS. Safari needs -webkit- in 5.0-, but was fixed just three months later in 5.1 (which shipped with OS X 10.7).
The most significant difference is that Android 2.3 needs -webkit-. Can I Use listed it as needed on 4.0, but I sent in a correction and they fixed within hours, so that’s good to know! Even on this site, I’m looking at 0.5%, which is way higher than those other browsers. If you’re site is specifically mobile-y, I bet this number is much higher.
It’s likely that the fallback of not having box shadows is no big deal, but I have seen a situation where it mattered so hey.
Even if you do need to add the prefixes, you can use SASS to make a mix-in so you only have to write one line instead of 4 for each browser whenever you need it :)
It could be a problem if you have a large set of code for a complicated site. If you use a lot of prefixes, you could potentially cut it by 75% using just the basic, if not more. SASS or not, depending on your code you could cut down file size by a significant portion by just using the standard version and not vendor prefixes.
I think the real issue here is when you’re using it for things that are access or important design issues. As Chris said, border radius on a container – not a big deal if you lose it. Border-radius on a circular button as part of a circular site motif in its design… much bigger issue.
I have been not using these prefixes since the middle of last year!
I’ve been wondering this lately, particularly because Compass puts
-moz-and-webkit-in your stylesheet, but Bourbon puts neither in there.Cheers for this.
I would say that using browser related prefixes was a bad idea from the start. I can agree on -experimental- or -beta- prefix to give the coder info that the final result may vary, but rewriting everything from browser to browser is weird and unnecessary.
I can remember one thing where there was a big difference in implementation. Gradients was defined different across browser in their early stage so different prefixes had sense I guess. Although, the implementation should be the same in every browser now as we learned on this mistake. It just should follow the specification and that’s it.
So one -experimental- prefix should be enough. Just to give a notice that the specification could change in the future. (Not the implementation!)
I’m a big fan of the prefix-free. Allows you code without prefixes and takes care of some of those older edge-case browsers. So you get some level of fallback and smaller CSS files.
For more than a year already, I personally have not used vendor prefixes for
box-shadowandborder-radiusanymore.And actually this exact week, I’ve been thinking about dropping vendor prefixes for
linear-gradientas well.SASS’ mixins are a HUGE help of course, and a few more lines of CSS code on my file have so microscopic performance impact, that is not worth it to worry about them.
Over at css3please.com, they list
background-clipwithborder-radiusto prevent “bg color from leaking outside the border.” Do you include that?According to caniuse.com and Chris’s logic, it seems like we usually don’t need to prefix
background-clipeither. Does that sound right?Sorry. Here’s the corrected link for
background-clipon caniuse.com.I’d say it depends less on viewer browser stats and more on whether you mind not having rounded corners and shadows showing on your site(s) for some users.
If your design copes without, then go with no prefixes.
I pretty much only use prefixes for background gradients and transitions these days. All the other stuff I leave to the standard.
I always prefix just to be sure that it’ll work on all if not most versions of a browser. I think W3C should do something to eliminate vendor prefixes, they’re just annoying.
When I need prefixing I just use this Sass mixin:
prefixes are a good thing for new features…but once stabilized, they can be dropped. Depends on how vigilant you want to be with old browsers. We can pretty much assume everyone has the latest Chrome, Firefox, Safarai, and at least IE8 now a days.
Not really. There are still a lot of mobile devices running older versions of OS (like Android 2.3.x, etc.) with its default web browser which will never be updated.
I use -prefix-free, which covers all of that, and I don’t have to worry about it either. I’d highly recommend it!
I don’t see any reason for a prefix rather than a vendor’s marketing strategy. It should be completely removed and banned by W3C. The code becomes too long
the reason for the prefix is simple: it allows browsers to release cutting edge features that are not a standard yet. I think prefixes are fine and should be used for new features, you just have to do some house cleaning every few years to get rid of them. Without prefixes, you would only be able to support one browser. Not many, until there was a clear standard.
@chovy, the problem is there are standards and implementation schedules for those standards and really should be followed by the browser producers so that way the whole process can be optimized.
Something to keep in mind is the performance hit
box-shadowcan have on mobile.It can be beneficial to user experience to only use
box-shadowon dektop version of a site, thus vendor prefixes are largely not necessary.What about linear gradients? Do we really need prefixes now?
Yeah, I’d like to know this. I have so many lines I’d like to drop. I just wish IE9 didn’t need that nasty filter…
This is a good post. I actually only just stripped prefixes and also dumped CSS PIE for a project I am working on. It’s 100% desktop and we have 90% of users in IE9.
“Second, you should only make decisions about feature support based on statistics from your own site and nothing else.”
I’d agree about 90% with this, and it’s certainly true for something as trivial as border radius or box shadow. But it’s too easy to look at stats and think you only have to deal with those browsers. But what you’re not getting from those stats is the visitors you could have but currently aren’t because your site doesn’t work adequately for them.
I think this is particularly true for mobile. For example, I have a couple really old sites that are absolutely terrible and scarcely usable on mobile. It’s not a surprise that these get very few visitors on mobile. If I just based my judgment on my visitor stats I would conclude that I didn’t need to bother supporting small screens, because only a tiny percentage of my visitors fit that category. That would be a mistake.
So, yeah, base on stats, but only with care and an awareness that stats aren’t the only picture.
I use the -webkit- border-radius prefix due to it being required for earlier versions of Android and iOS, but not the Firefox one as users on Firefox 3.6 is less than 0.001% of our web traffic.
CS3please.com is a good guide for if you should include prefixes or not:
http://css3please.com/
If you are actually working for a customer/company. I’d recommend using the prefixed versions along with the non-prefixed, just to lower the incompatibility as some company’s are a bit lazy in terms of updating there environments.
I keep using them until the previously mentioned browser versions became dinosaurs. Though “size” of the css file “might” be a problem, it is quite a non-issue compared with the “size” one saves by actually using css3 for styling as to png-files that can become rather bloated in a complex design. Either way, I am looking forward to a prefix free web! (or at least for those elements that aren’t “experimental” anymore).
prefizr.com automates this for you. And for all you Sublime users out there, there is a handy plugin built on it.
I use this http://leaverou.github.com/prefixfree/
I’ve left prefixes outside my css in projects non involving mobile. In other circumstances, I use only
-webkitto (try to) target all mobile webkit-based browsers out there.