CSS3 Best Practices

Since CSS3 has become such a big deal in the future-thinking minds of web designers today, I think it would be appropriate for front-end developers to begin formulating some best-practice habits and techniques so that any CSS3 development we do is done right, and we therefore are able to get CSS3 development off to a good start.

By no means do I assume that everything in this article is etched in stone and error-free, but I think this will be a good starting point for this topic, and I will be happy to add to or amend any points that anyone feels need adjusting or clarification.

Consider this a starting point for discussing best practices for CSS3, especially since there don’t seem to be many articles available yet that exclusively discuss CSS3 best practices.

Think Progressive Enhancement

The most accessible and widely-supported websites are those created with progressive enhancement in mind. Standards proponents have for years discussed the benefits of accessible, backwards-compatible content — specifically in relation to JavaScript and Ajax-based websites and applications.

The same principles apply to CSS3 development. Website and app visuals that are critical to the user experience should not be dependent on CSS3. CSS3 should be used to enrich and enhance an already fully-functional experience.

Since CSS3 has now crossed into a gray area of event-driven features, more care needs to be taken to ensure that non-supporting browsers do not greatly hinder the user experience.

Organize and Comment Vendor-Specific Syntax

Unfortunately, since many CSS3 features are supported with different proprietary syntaxes, this means that some parts of your CSS code will become bloated. But you can still keep those areas of your code organized by inserting comments indicating the browser version that the code is for, and also by keeping the different lines of code in a recognizable order with the standard format listed last.

It’s also best practice to list your CSS3 items last in the CSS declaration. So, for example, if you’re rotating an item with CSS3, your code might look something like this:

In the example above, I don’t believe the standard syntax is supported by any browser, but this code just serves as a way to theoretically demonstrate the method of listing CSS3 properties last, and the standard property at the end of the declaration. Keeping the CSS3 properties last will also ensure that any “fallback” properties are in their correct place. Which brings us to the next point.

Use Fallbacks for Background-Related Enhancements

Some of the new CSS3 features require that the background property be used. The background property is nothing new to CSS, but the possible values have been upgraded with CSS3, allowing use of RGBA, HSLA, gradients and even multiple background images.

In most cases, a non-supporting browser will still display a similar feature, and the lack of an HSLA or RGBA color will not affect the result. But with a gradient, you may need to declare an IE-only fallback in a separate stylesheet, or a background color that it will fall back to if a gradient is not supported.

In the case of multiple backgrounds, be sure to list the most important element first, so it serves as the fallback.

For most situations, I don’t think this particular practice will be necessary, but it’s good to keep in mind the possibility that a fallback color or background image may be needed.

Use Rotations, Animations & Scaling Sparingly

Although WebKit-based browsers have opened up some incredible possibilities with CSS3, we don’t want to get carried away. Subtle, tastefully selected events and animations are usually the best choice.

There’s a reason that Flash intro pages became a tiresome practice; they were often self-indulgent and pretty pointless, doing nothing but slowing down the user and making them download more resources than necessary.

To prevent the web from becoming filled with CSS3 trash, let’s use the new features carefully and in a dignified manner that doesn’t harm or slow down the user experience.

Be Careful With Typography

Making enhancements on text with CSS3 has become more common, and many sites are now employing the @font-face technique to use custom fonts.

Make sure that any typography-related enhancements do not affect the readability of the site. Sometimes, as designers, we take an overall view of a website’s layout, and try to make every little detail as beautiful as possible, but forget the most important thing: That the content should be accessible and readable.

So, if you’re considering using shadows, gradients, or transforms on typographical elements, think twice about it, and strip out any unnecessary enhancements that cause undue harm to the readability or accessibility of the site.

Test in All Browsers With Fallbacks Enabled

Testing of course is one of the most important parts of successfully adding enhancements. But the advent of CSS3 features may add more pressure in this area.

Don’t be content to just test the enhancements at full-throttle in the most supportive browsers; test in the non-supporting browsers while temporarily removing some of the enhancements, maybe one by one, to see the experience with fallback options enabled.

This makes commenting and organizing code even more important, and will likely add more quality assurance testing to many design teams’ schedules.

What Did I Miss?

Surely this is not a complete list. Add your comments below if you feel there are important CSS3 enhancements that require a best practice method or technique, and I’ll be happy to add to a few end-points to this article to round it out.

25 Responses

I think CSS3 is great but people need to exercise some caution and restraint when using it. It’s very easy to get carried away with transitions and rgba etc etc but people need to remember that not everyone is using WebKit based browsers. Remember, even Firefox (apart from Alpha / Nightly versions) doesn’t support transitions yet.

Using subtle text-shadow’s and other tweaks here and there is great as they can really add to a site, they can also degrade nicely. As the article above points out, @font-face has opened up loads of opportunities but you should never use it where it would adversely effect readability and accessibility.

Absolutely right. Webkit is wonderful, but its market share is very small (just bigger than Opera). So, I usually choose Javascript solution when I have to implement something that can be done with CSS3 for better compatibility. I don’t like that, but it needs more time.

I’ve been thinking about the browser specific rules and I’m leaning towards grouping the browsers together at the end of the stylesheet, so that when a browser starts to support the feature it will be easier to remove a few browser specific rules from a single section, than hunt through the whole style-sheet and take them out one by one…

You’re absolutely right! So glad you pointed that out. I’ve made that mistake so many times in tutorials, because I’m more used to commenting JavaScript and not so much CSS. Usually CSS doesn’t need comments, because the selectors tend to be self-explanatory (e.g. #sidebar, etc).

CSS3 is just what I’ve been specting since I turn in to a Web Developer, using a really new tecnology make us be always like much in front of others, and permit us to create good stuff and be already used to it when the tecnology is released officially, but as always I’m pretty sure that Internet Explorer will cost many time and “brain” to us becouse of the incompatibilities and the lack of updates by the windows regular users.

I’m still not using CSS3 much, and probably won’t until it is much more widely accepted, but things like what this article discuss are still necessary points to emphasize. A lot of people are already heavily using CSS3, and they need to do so responsibly with the fact that it’s not 100% accessible just yet in mind.

Thanks for this one, makes me feel a lot better knowing other like-minded individuals are coding the same manner! I was just thinking about moving all the css3 to the end as the post above suggested, good thinking Tony!

Love the idea of setting standards before CSS3 becomes the norm. Am currently working on 3 different web sites and am constantly looking for ways to ensure the fastest loading times with just the right amount of pizzaz. Love the standards talk as well as the time saving tips I receive from you guys and wish I could one day add some as well.

Make sure that the type face you’re use looks good in Windows. Hints in most sucks and Windows’ anti-aliasing isn’t very good. So thin parts of letters can look really jagged. Even with many of the new Google hosted fonts and typekit.

I have questions regarding CSS3 transform property. Say I apply some transform to the main div of a website. Then can I override the transform in the banner div or main-content div like -moz-transform: none !important;? If I can do this, then it is like I apply the transform to the background of the main div, and the rest stays the same. I tried with -moz-transform: none !important, even as inline style, but it didn’t work. Any ideas or suggestions?

I’m not sure why you would even want to do that. Generally speaking, you should never use the “!important” declaration in your CSS. It should only be used in last case scenarios, where nothing else works, which is very rare.

Also, the transform you’re referring to on the main div is not going to be inherited by the other divs, so why would this be necessary? Maybe I don’t understand your question.

It’s nice to see more subtle uses of CSS3 being added to projects – it doesn’t always have to be large scale effects or animations. A little box-shadow or a slight rounded corner does a lot more (without hindering users who can’t see it) than full blown transformations

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address. No foul language, please. Thank you for cooperating.

Instructions for code snippets: Wrap inline code in <code> tags; wrap blocks of code in <pre> and <code> tags. When you want your HTML to display on the page in a code snippet inside of <code> tags, make sure you use &lt; and &gt; instead of < and >, otherwise your code will be eaten by pink unicorns.