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:
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.
TestTest
- 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
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!)
Pingback: Tweets that mention CSS Best Practices and a Return to the Basics – iKeif – tech and social media geek, mootools fan, and a ton of links — iKeif - tech and social media geek, mootools fan, and a ton of links -- Topsy.com()