Web design is (or perhaps should be) all about good practices and web standards. In spite of that, it's pretty amazing how many designers just learn by doing and do what works rather than what's good. Here are a few tips I wish I had been told about from the start.

1. Include a color scheme in your stylesheets

That way, when you're creating a border color for some random form element and you can't remember exactly what shade of light blue you have been using, you don't have to search through the CSS declarations until you find it. Here's an example from yours truly, CapsizeDesigns.com:

Pretty nice, huh? It will also GREATLY help with modifications later down the road when some code monkey in Mongolia gets ahold of your precious CSS and screws around with it. We all know how frustrating it is to check on a beautiful site that you finished a year ago, only to find out that maintenance and updates have turned it into internet poop. Make it easy for that Mongolian guy to keep it looking as nice as you built it.

2. Create a table of contents

For a smaller site, this may not be necessary, but as your stylesheets begin to look like your bible, you're gonna be glad you have it. Here's an example taken from a Smashing Magazine post:

3. Keep properties in alphabetical order

This is just something I like to do. I find that it saves you a second or two when looking for a specific property. For example, try finding "color" in this alphabetically arranged declaration:

as opposed to this one:

Either way, it only takes a second or two. But I bet you liked the first way, didn't you? You did.

4. Learn the shortcuts

There are a number of CSS shortcuts that will make your files look a lot shorter and cleaner. These are pretty common, and I'm willing to bet that most of you treat this one as a no-brainer. But for those who don't, take a look at this:

and compare it with this:

5. Include a reset stylesheet

This one also should hopefully be a no-brainer. A lot of the browser inconsistencies that inexperienced web designers get so frustrated with are just because the defaults that browsers use on the pages they display differ so much from one another. Therefore, before your CSS begins, throw in a reset stylesheet that resets all of those values to the same baseline. Take it from me, if you're not using some sort of reset, you should be.

The simplest (and WORST!) looks something like this:

This will certainly help a lot, but it's a bad idea. You're forcing the browser to apply a style on EVERY SINGLE element, which is pretty heavy on the rendering agent. The most widely accepted solution is to list all of the things that need resetting and then reset them all together, rather than resetting EVERYTHING there is. Eric Meyer's "Reset Reloaded" is pretty much the big papa here, although YUI! has a pretty popular one also.

Now, it's worth mentioning that this is one of those "learn the rules, then break the rules" things. Quite a few CSS gurus, including the awesome Jonathan Snook, argue that CSS resets are in fact detrimental to a site's development because you just have to go back and re-specify all the things that the reset takes away. Snook argues that he's ok with the tiny browser inconsistencies that come about in any site, especially if it saves him the time and bandwidth of a reset and then the code to fix the reset. However, if you're still ripe in your CSS skills, go with the Meyer reset. You can change your mind after you've done it a few dozen times.

6. Use a CSS framework AFTER you learn to do it yourself

I've said before that I'm a huge fan of CSS frameworks (heck, I even made one for myself). They save you tons of time by helping you focus on the designing rather than the coding. However, I think it's really important to get a good handle on CSS before you resort to Blueprint, YUI, LogiCSS, or whatever. The problem with CSS frameworks is that they have to be general enough to work for every site but specific enough that you don't have to re-code a lot of them. This is darn near impossible to accomplish, and you can be pretty sure that you're going to have to override a few things from the framework to get your site working just right (especially with a fairly robust one like Blueprint). This involves looking at the framework's code to figure out what's going on.

Believe me: if you don't have a good handle on CSS, you're not going to have any idea how to change around a framework's code. It's hard enough to try and figure out what's wrong with your code. Try figuring out what's wrong with someone else's code that you've never seen before. If you don't understand what float: left REALLY means or can't really grasp the difference between the different types of positioning or have trouble understanding the border box model, then you're up a creek.

Just do yourself a favor and build a few sites from scratch. Not only will you be able to understand what frameworks do for you, but you'll be able to appreciate them (if you're into that kind of thing), or disregard them altogether (if you're not).

7. Design for Firefox and then fix it in IE

Since IE is the most popular browser (if you can call it that), there's a tendency for up-and-coming designers to make sure their sites work first and foremost in IE, and then try and do what's needed to make them work in Firefox (and hopefully Opera, Safari, etc.). This is bad.

First of all, designing in Firefox is just easier. You've got the Web Developer's Toolbar (if you don't have it, then stop reading and get it), Firebug (oh yes), and tons of other addons to help you out. Secondly, Firefox is just about as standards-based as you can get. This means that a site that works in Firefox is more likely to be valid CSS than a site that works in IE.

So here's a good workflow. Start designing in Firefox. Whenever you get a large part accomplished (say the navigation or the header or the grid), check it in Opera. Since they are both very similar in their devotion to web standards, the site should look almost identical in both browsers. If it doesn't, then you're probably in trouble and you have an error somewhere. When your design is completely finished, THEN check it in IE. Don't freak out when it looks bad, because most of the time it will. Luckily, Microsoft recognizes this and gave us a conditional tag that only IE will recognize. This means that after all your regular stylesheets, you can make and IE ONLY stylesheet that fixes all the problems that showed up. Here's the syntax:

8. Use HTML tags to cut down on classes and ID's

Lots of new designers stick everything in paragraph tags, and put an ID or a class around something that needs to stand out or look differently. This works, but it's not the best way. There are a plethora of HTML tags for exactly that. If you want something to bold, don't add class="bold" to the paragraph tag, just use a strong tag. Then, in the CSS, make sure you've got something like:

If you need italics, use an em tag. If you're quoting somebody, try out the blockquote tag. If you want preformatted text, use a pre tag. The list goes on and on. Check out a complete list of HTML tags to get the full story. Tags are your friend. Use them. Less ID's and classes and div's means happier coders and more beautiful code.

9. Use a diagnostic stylesheet

Somewhere along the web design timeline, somebody had the brilliant idea of creating a stylesheet that would highlight any problems you've got in your markup. With this diagnostic stylesheet, you can highlight links with href=# or links without a title or tables without a summary or images without an alt attribute, etc. Eric Meyer has a nice one that I've grown to love.

Of course, tools like the Web Developer toolbar do all of this nowadays, but you'll often find yourself trying to design on a computer without install privileges so you won't have that luxury.

10. Take advantage of the "Cascading" nature of CSS

This seems not even worthy of mentioning, but it's one of my pet peeves. If you have two elements that are almost exactly alike, then specify their similarities in one declaration, then separate their differences. For example, if you've got two different types of headers that you're using, and they're both identical to each other except that one needs to be in italics, I'll tell you what to do. It's much cleaner than completely separating the declarations and adding unnecessary lines to the stylesheet. (NOTE - normally you would just throw and em tag around the italics one, but for the sake of illustration, pretend that doesn't exist).

Furthermore, be aware that an element can have multiple classes. So if you want a paragraph to be bold, italicized, and have a blue background, you don't have to specify one class that has all of those properties (class="bluebgbolditalics" is a definite no no). You can just have a "bold" class, an "italics" class (once again, pretend that em tag doesn't exist), and a "bluebg" class (or perhaps something more semantic than that). Then just throw in:

That way, you can reuse each individual class for other elements, instead of the bluebgbolditalics class that would never see the light of day again.

Any more common beginners' mistakes? Let's hear 'em!

This entry was posted on Friday, June 20th, 2008 at 12:22 pm and is filed under BlueTrip, CSS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.