The new features of CSS3 bring with them complexity and new things for us to screw up. This article will help keep us in check as we start using these new features.
Yes, you should be using CSS3 today. Let's skip right past that whole discussion and start talking about how we can write better CSS3. A lot of the new features of CSS3 are just plain more complicated. They have complicated syntaxes. We have to use strange "vendor prefixes" to get them to work in as many browsers as we can. We have to understand cross browser inconsistencies and stay on top of evolutions.
Said another way, there is a lot more stuff for us to screw up. Let's take a look at some possible mistakes we can make while crafting our CSS using CSS3 features (and how to avoid them).
Leaving Out Vendor Prefixes
A "vendor prefix" is an add on to the beginning of a CSS property to make it specific to a browser rendering engine. The mere existence of these prefixes is actually rather cool. While they might seem contrary to the idea of "standards" and a pain to deal with, they are a symptom of browser vendors trying to move quickly and get us testing new features before the spec they are based on is even done yet. Good on ya, browser vendors, keep up the good work.
For the CSS3 property "transform", there is a Mozilla prefix, `-moz-transform`, for browsers like Firefox, SeaMonkey, and Camino. There is a WebKit prefix, `-webkit-transform`, for browsers like Safari and Chrome. There is an Opera prefix, `-o-transform`, for Opera. Finally there is an Microsoft prefix, `-ms-transform`, for Internet Explorer.
Not all of those four prefixes are supported for every single CSS3 property. In the case of transform, they all are. Here's the deal: definitely include all vendor prefixes whenever available.
It's easy to forget or be lazy about adding every single prefix. Don't. Maybe you don't have many visitors using Opera or you hate IE with a passion. Get over it. Give every visitor you have the best chance at the best experience you can give.
I'd encourage you to read this article by Eric Meyer regarding vendor prefixes if you are interested in learning more about this.
Not Listing the Non Prefixed Property Last
We are in a very interesting stage in the maturing of CSS3 right now, where some parts of it are considered finished and browsers are now removing (or at least supporting both prefixed and non-prefixed) versions of properties. Where this gets especially hairy is when there are syntax differences between them. Before you get up in arms as to why there are syntax differences, remember that was the whole point of prefixes to begin with: to make sure a live implementation of the real property isn't broken.
The important thing to remember here is to always list the non-prefixed CSS property LAST. If a browser is supporting the non-prefixed version, it means they are confident they have implemented it correctly and to the final spec. That is the version we should be using (that's why we put it there at all). Listing it last means it will override the prefixed version and ensure that happens.
If we don't do this, there are some real problems we can face.
Don't do this:
.not-a-square { /* These do totally different things */ border-radius: 30px 10px; -webkit-border-radius: 30px 10px;}
Safari 5 supports both of these properties in different ways. The spec version will round the top left and bottom right corners 30px and the top right and bottom left corners 10px. The vendor prefix version will round all four corners with a horizontal radius of 10px and vertical radius of 10px. Totally different. If you list the vendor prefix last, that will override the correct version and will be wrong forever (or until WebKit drops the vendor prefix).
For a bit more on this topic, you can read this article by me.
Not Staying Up To Date
Google Chrome has gone from version 0 to version 10 (with 11 on the way) in just a couple of years. Things are moving pretty fast in the browser world lately. Along the way, there are some changes in the way that they support things, CSS3 included.
One recent example is how Mozilla and WebKit handle linear gradients. They used to have different syntaxes to do the same thing:
The Mozilla version is simpler and actually closer to the spec then the WebKit version. Now in the latest WebKit browsers (Chrome 10, and what will likely be Safari 6), they are moving to a similar (but not exact) format as Mozilla uses.
WebKit will be supporting both syntaxes but it can be assumed that ultimately the older more verbose syntax will eventually be dropped. Make sure to stay up to date on this stuff! It's kind of our job.
I recommend the fabulous CSS3 Please! - an online resource for copy-and-paste CSS3 snippets that have all the correct CSS3 properties in the right order. They have stayed up to date very well.
Using Bad Formatting
This one isn't a mortal sin like the previous mistakes are, but still and important thing to consider. We've established that CSS3 is more complex than CSS 101 `color: red;` kind of stuff. There starts to be a lot of values and when you toss in the vendor prefixes, things can get ugly and hard to real quick.
CSS is pretty lenient about whitespace, so use it liberally. You compress and Gzip your resources anyway, right?
Going Way Overboard
You can make things spin. You can make things grow in size. You can make colors fade. You can use 10 different fonts. You can make every element on your page slathered with shadows.
I don't need to tell you folks to use good taste. You're designers for pete's sake. You read a web designer's magazine.
What I do need to tell you is that even if you do use good taste, many of these CSS3 features have page performance concerns. WebKit has a very cool keyframe animation feature (would you call that part of CSS3? sure, let's.) If you animate just a few elements on the page, you'll see some pretty decent CPU usage. Make it animate infinitely, do a couple different elements, and put other CSS3 features on those elements, and you'll likely see some lag, some choppiness, maybe even some browser freezing.
Another example is large inset box-shadows were causing major scrolling problems in WebKit. The fix is complete, but that rollout takes a while and there will still be users on old versions for some time.
There needs to be more research done in this area, but for now just be aware of this and if you are seeing performance issues, see if removing some CSS3 features helps it.
Not Thinking Mobile
Another seriously cool CSS3 feature is media queries. Now we have a way to test for the environment we are in and write specific CSS for that. Among the best and consistently supported media queries are the ones involving width. Right within your main stylesheet, you can include styles that only take effect on very small screens:
@media screen and (max-width: 480px) { /* Mobile stylings */}
You might take the opportunity to take away elements you deem less important. You might also want to make sure images don't cause unneeded horizontal scroll. And remember the performance issues we talked about? That goes doubly so on mobile devices where going overboard might cause even more severe slowdowns and be less effective visually. Consider:
