Best Practices for CSS3

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:

#rotation {
	float: left;
	width: 200px;
	-webkit-transform: rotate(-5deg); // chrome, safari
	-moz-transform: rotate(-5deg); // firefox
	-o-transform: rotate(-5deg); // opera
	transform: rotate(-5deg);
}

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.

So, you might need something like this:

#element {
	background-image: url(images/bg-transparent.png);
	background-color: rgba(98, 135, 167, .5);
}

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.

Source: impressivewebs