Welcome to the second installment of CSS DO’s and DONT’s, our monthly blog series designed to provide useful, time-saving CSS tips while making note of some bad habits website developers tend to repeat in their code, despite the negative impact on workflow.
Today’s DO’s and DONT’s:
DO Comment a Reference Guide into Your CSS File
and
DON’T Forget to Validate Your Code.
Let’s get started.
DO Comment a Reference Guide into Your CSS File
When you’re deep into the code of any given website, you’ve probably memorized every hex color used in your design and are able to rattle off style values at will, even from a sound sleep. Flash forward to three months after launch and try to remember what the hex is for that sole yellow sidebox four pages deep. Unless you have a photographic memory, chances are you won’t remember!
Taking a few extra minutes to comment a style guide at the top of your CSS file could very well turn out to be your own most useful resource down the road. Rather than having to scan 500 lines of code to locate your yellow hex, you could readily locate it at the top of your document in a matter of seconds.
Style reference guides are also particularly beneficial to those working within a team setting of any kind, whether agency, in-house or virtually scattered across the globe. Even if only one team member is responsible for the markup of a website, the programmer on the team will find the guide handy when they need to style a report, while the graphic designer may reference the guide to pull colors for a custom icon set.
An example of a reference guide outlining the basic color scheme used in the website:
/* COLORS
blue #0033cc
light gray #efefef
navy #330066
orange #d97510
*/
Or, you can break it out by element:
/* COLORS
container #aeaeae
container border #333333
nav bg #330066
nav hover #d97510
image thumb border #176f77
image thumb border hover #275c61
*/
You can even take it a step further by including other style values, such as border or div widths. The more detail you provide, the handier your reference guide becomes:
/* VALUES
container #aeaeae 900px
container border #333333 1px solid
nav bg #330066 125px
nav hover #d97510
image thumb border #176f77 1px dotted
image thumb border hover #275c61 2px solid
*/
There are no set rules for marking up your reference guide in any particular way – just make sure you use a format that meshes well with your own semantics and workflow!
DON’T Forget to Validate Your Code
Although validating your code might seem like an extra step, especially when everything is rendering properly on all major browsers, here are a few thoughts to ponder:
1. Error-free code renders faster, meaning less download time for your website visitors.
2. Some search engines cannot properly index XHTML/HTML that contains serious errors.
3. Just because your code renders properly on all browsers this month, doesn’t necessarily mean that it will render properly with the next release of a major browser. Most browsers are becoming more standards compliant with every version release.
4. Browsers that are currently under development are probably being written in compliance with the World Wide Web Consortium’s (W3C) set of standards – validating your code now will protect your website from future browser incompatibilities.
5. Publishing valid code is a positive reflection of your abilities and attention to detail.
6. Unless your code has some serious issues, validating both your XHTML/HTML and CSS is a fairly quick task. Conversely, if your code does have serious issues, your company or client would probably greatly appreciate you going the extra mile to fix said issues.
If you’re a Firefox user, there are a number of extremely useful extensions that allow for one step XHTML/HTML validation. I prefer to use Marc Gueury’s HTML Validator. It puts a handy icon in your tray that you can click while viewing your development progress to pop open an organized three pane window displaying your code, page errors, and a useful help section, as shown in the screen shot below:
Once you have fixed your XHTML/HTML errors, pat yourself on the back for a job well done and move on to validating your CSS.
The W3C also offers a free CSS validation service that is quick and easy to use. Simply input your website address, and in seconds you are presented with a breakdown of your CSS errors and warnings. Typically, errors are flagged when there is an improper value attached to a particular property, whereas warnings are generated to flag potential code issues such as a background-color value and color value that are the same for a single property.
Up Next Month: DO Properly Organize Your CSS File and DON’T Overuse Conditional Comments and Hacks.
You can catch up on our series by reading last month’s CSS DO’s and DON’Ts.
Image: geirarne
GD Star Rating
loading...
