CSS Best Practices and a Return to the Basics

This article is not about learning CSS. It’s about having a set architecture in a project when moving forward. One of the first things in beginning development is setting in place a best practice procedure when moving forward – it’s not saying “there is only one way”, it’s saying “for this project, this is how we are moving forward.”

Rule: Choose a Browser Reset Style Sheet

Choose one, or don’t use one.

This helps you on your cross-browser journey. If we reset all browsers to zero, it allows you to spend less time figuring out why margins are inconsistent amongst your unordered list elements (<ul>). This also sets you up to have a default font-family and consistent font-sizes, line-heights, etc. This is most important when cross-browser similarity is a high-concern.

CSS Resets are Bad, M’Kay?

Jonathan Snook stated that he “…okay if the various browsers show things slightly differently.” Jens Meiert also states CSS Resets are bad because they essentially add up to a defined style being overwritten repeatedly, adding to network latency due to the multiple requests for CSS. Then follows up with the comment of using * { margin: 0; padding: 0; } which itself is a bit of a hack and causes performance issues.

To be honest, the argument that CSS Resets/the * hack are a bit of a red-herring. For the majority of clients/sites I’ve worked on, this has been an incredibly minor concern. We’re talking milliseconds. Not even on the radar type performance hits. If you want to squeeze every millisecond (and I do) this is kind of an extreme (even for me) case.

Unfortunately, not all of us are as lucky as Snook and we work with clients/creatives that are not okay with things being a few pixels off sometimes. Personally, I’m with Snook.

Should You Choose To Reset

You have several to choose from:

• Toby Miller’s Equalizer
• Eric Meyer’s Reset
• YUI’s Reset

Rule: Link States

This is referred to as the “LoVe HaTe” rule. :link :visited :hover :active
This relates to CSS specificity, below.

Rule: CSS Specificity

Eric Meyer has a great article on CSS specificity in general that I find lame when sites try to duplicate his article with their own “twist.”
I fully admit, I suffer from over specificity. For good measure, you can read Google’s article about CSS specifity and the increase in performance by using effective CSS selectors.

To reiterate certain aspects, DON’T put a class and ID on everything.

div.imageHolder img#imageHolderImage /* this is BAD */
div.imageHolder img /* this is BETTER */
.imageholder img /* ding ding ding! we have a winner! */

As well, don’t code things inappropriately, i.e. use nested divs/p to generate what is essentially an unordered list.

	
Test
	
Test



	
Target the first item
	
General list item
	
Target the last item

Rule: Naming Convention

We won’t dwell on this. BE GENERIC. It’s better to have “.active” or “.select” and NOT “.greenActiveText” – what happens when green active text becomes orange? Now you have a poorly named class.
Also, pick a naming structure and STICK TO IT. camelCase? Dashes-instead? Hell_underscores_are_okay, AS LONG AS YOU ARE CONSISTENT. Do not change it up. This is extremely important walking on to a project. If you walk in and the prior developer is doing it different than you are used to, ADOPT THEIR STYLE, DO NOT REWRITE IT, ADD TO IT, OR MAKE IT MORE COMPLEX THAN NEED BE.

Rule: Shorthand

Use it. Know it. Love it.

div {
	background-image: url("to/some/image");
	background-repeat: repeat-x;
	border-width: unit;
	border-style: (solid dashed dotted double);
	border-color: color || #hex || (rgb / % || 0-255);
	color: #669900;
	margin-top: 10px;
	margin-right: 9px;
	margin-bottom: 8px;
	margin-left: 7px;
	padding-top: 10px;
	padding-right: 5px;
	padding-bottom: 10px;
	padding-left: 0px;
}
div {
	background: url(to/some/image) repeat-x;
	border:border-width border-style border-color;
	color: #690;
	margin: 10px 9px 8px 7px;
	padding: 10px 5px 10px 0;
}

Notice the “0” has no identifier. It doesn’t need one. Notice 13 lines became 5. Love that. We also dropped the quotes to prevent any possible browser errors. Get to know your CSS shorthand.

Rule: Browser Targeting

For the love of God, they’re called hacks for a reason. They are hacky. They shouldn’t work, but do. You could fuck another browser down the line. You could introduce errors. DO NOT USE BROWSER HACKS This is a bigger sign that *you* are a hack and a not a proper developer. These are the “once in a lifetime” things that come up.

Except for IE.

Fortunately, IE has a nice, clean targeting system. Conditonal comments. If you target IE, use Conditional Comments.

Rule: CSS Behaviors Require JavaScript

If you’re writing CSS Behaviors, move it into JavaScript. Plain and simple. There is no reason to have CSS behaviors. At all.

Rule: Organize Your CSS

I know this one can be a bitch. The project can change. Your initial strucutre may not make sense. But try to organize it to prevent redundancy.

Alphabetize Yo’ Self

I alphabetize my CSS because I find it easy to read, search, and peruse. I also use a code highlighter in jEdit. Others group it by property (font styling, positioning, dimensions). I prefer my way, but that doesn’t make it right. Just when I’m leading the project.

Rule: Comment, Comment, Comment!

Comment the shit out of anything you are handing off. Eat the bytes. But don’t go crazy. /* this is a comment */ not /*——————– (several lines of this) CODE COMMENT (repeat several lines) ———-*/ Keep it simple. Keep it common sense. Break it up by section (however you organize your CSS).

Rule: The DO NOT Do List:

Don’t do these.

Don’t Use Inline Styles. Period.

Inline styles defeat the whole “separation of content and design.” Maintenance becomes a bitch, frankly. You also add to page weight, and can cause issues when a developer doesn’t realize you’ve done things inline and their properly coded external styles are not working properly.

But Keif, I do this all the time in development… – that’s fine, Timmy, but if you “accidentally” leave one in to production, or check it into SVN/CVS/Git and try to act like it’s not your fault, you’ve proven the point why you shouldn’t do this.

Reuse a “Standard” Set of Specific Styles

I don’t mean reset. I don’t mean element specific/font styling type items. I mean don’t use classes that are specific. #width100 .marginLeft25. This is representative of bad coding in general.

Now, this is a brief overview of many “best practices” I try to run with and improve upon. Google CSS Best Practices and you’ll find a slew of additional resources. Not all of them will agree with me – but that’s not the point. The point is understanding them, and recognizing that someone else’s preference may override your own, and my not be technically wrong. If you fail to recognize this, you need to reconsider your role and what you’re doing – you need to be both a team player that can adapt and evolve, and an innovator should you be charged with leading the effort.

What do you have? Send me your best (or worst you’ve seen!)

Tagged as: creatives, css, equalizer, performance issues, style sheet, styling