1. Open the file /private/etc/hosts, and add one line for each virtual host you want like so:

   127.0.0.1	newhostname
   127.0.0.1	othernewhostname

   The IP listed should always be 127.0.0.1, and the name of the host can obviously be whatever you choose.

2. Open your Apache configuration file (/private/etc/apache2/httpd.conf on Mac OS X Leopard), and add these lines if not already present (you can add them at the end of the file):

   NameVirtualHost *:80
   Include /private/etc/apache2/extra/httpd-vhosts.conf

   The Include directive tells Apache to look in a separate configuration file for virtual hosts, which makes it easier to manage. Make sure you use the path that corresponds to your installation of Apache. The path listed above corresponds to Leopard.

3. Open the configuration file (you may have to create it, if it doesn’t exist already) that you pointed to in the main httpd.conf file, and add the following for each new host name you specified in hosts above:

   <VirtualHost *:80>
   	ServerName newhostname
   	DocumentRoot /path/to/root
   </VirtualHost>

4. Restart Apache. The easiest way to do this on a Mac is to go to System Preferences… > Sharing and uncheck “Web Sharing”, then check it again. You should then be able to use your browser to navigate to http://newhostname/.

This was just an overview. For more detailed information on setting up virtual hosts, see: Apache Virtual Host documentation.

A very easy way to manage virtual hosts on Mac OS X is through a handy application called VirtualHostX, which is free, except that it limits you to three hosts. You can register it for a small fee to remove this restriction.

Note that while some Web developers prefer to rely on their development software to format their style sheets, I do all this by hand (i.e., I type the code directly as opposed to manipulating it through a GUI).

Filename

The first thing to consider is naming your style sheet appropriately. I always name my main style sheet baseline.css, because it serves as the style sheet from which I can build more specialized styles (e.g., a print version of the site). Where I need a style sheet for a particular media type such as print or projection, I use the name of the medium, giving us print.css and projection.css respectively. More often than not, I also want to include a separate style sheet for Internet Explorer that I serve through conditional comments. I name this file ie.css, or if I’m targeting a particular version, I include the version number (e.g., ie6.css).

The Header

At the top of every style sheet that I create, I make sure to describe the file’s context. I use a template that I keep whenever I start a new CSS file:

/*
author: [my name and URL]
project: [the URL of the site I'm working on]
scope: [where the style sheet applies (usually "site-wide")]
*/

You can get as detailed as you see fit for the scale and needs of the project you are working on. For instance, I might want to denote a version number with version: 1.2. What I’ve included above is the bare minimum.

Aside from being useful to others working on the same project or someone simply taking a look at your source, I find this information invaluable when, for example, I’m looking through a bunch of files on my computer called baseline.css and I need to find the one that corresponds to example.com. In general, the more documentation you provide with your code, the better.

Structure

Especially on bigger projects, keeping the body of your style sheet organized is a must. I always break the body down into sections and I employ easy-to-see headings to mark each section I make. Here is the style I use, but of course, the format is up to you:

/* THIS IS A HEADING
***************************************************/

As for what I find useful in terms of making divisions, it depends somewhat on the project, but I usually have at very least the following sections:

1. ELEMENT DEFAULTS
2. LAYOUT LOGIC
3. PAGE-SPECIFIC

Item (1) is where I put all of the rules for plain old HTML elements such as p {...}. Item (2) describes the way that pages are laid out. This section contains rules pertaining to structural elements that are common to multiple pages. Item (3) contains rules pertaining to the content of specific pages. I like to keep this separate in order to avoid clutter in the rest of the style sheet. For the most part, the sections move from more general rules to more specific ones. On larger projects where I divide the body of my style sheet into many sections, I even include a table of contents.

Rules

The following is an example of a rule with only one property. I like to keep these on one line:

p { line-height: 1.5em; }

When I have a rule where I’m setting multiple properties, I break it up over separate lines:

p {
	line-height: 1.5em;
	font-style: italic;
	}

Note that the only part not indented is the selector, so that you can easily scan the document with your eyes for a particular element or class in the same way that bibliographies are indented so that you can scan the left margin for an author. Where I am grouping multiple selectors, I like to keep them on separate lines for this purpose:

p,
li { line-height: 1.5em; }

Note also that I always include the semicolon following the last declaration in my rule, so that if I add a new declaration, I don’t need to worry about what’s already there.

This particular format is just a suggestion. Your own style may vary according to your preferences as long as it is legible and consistent.

With their first LP as my only reference to their music, I was surprised to see how electronically based their performance was. Performing with three permanent members of the band were two additional members who perform with them and are reported to appear on their upcoming album. Yeasayer opened with a song that I didn’t recognize and followed it up with material from All Hour Cymbals including their singles "Sunrise" and "2080," and "Tightrope" from Dark Was the Night. I was slow to recognize much of what they played since their performance was not a direct translation of their recorded music but in some cases a total reworking, often incorporating harsher, electronic sounds not present on their album. To my delight they performed all of their electronic beats on the spot with drum pads alongside (two) traditional drum sets.

They ended their set with a new song (the only one they announced as being new), which had a sound strangely similar to that of Animal Collective. All in all, the show was energetic and crowd-pleasing, thanks to the upbeat energy of their music and their stage presence, despite the sudden downpour which lasted the duration of their performance. I look forward to their new album to be released sometime this year.

There are two types of conditional comments: so-called down-level hidden and down-level revealed.

down-level hidden:

<!--[if IE]>Show this to IE<![endif]-->

down-level revealed:

<![if !IE]>Show this to everybody but IE<![endif]>

Browsers that don’t support conditional comments will ignore those that are down-level hidden, interpreting the code as a standard HTML comment; but down-level revealed comments will reveal the HTML content to other browsers because the conditional statements are ignored as invalid HTML tags (more on that below).

Syntax

The condition, which is enclosed in brackets [ ], always begins with if. Next, we have an operator such as ! used above. The possible operators are:

!

NOT

lt

LESS THAN

lte

LESS THAN OR EQUAL TO

gt

GREATER THAN

gte

GREATER THAN OR EQUAL TO

&

AND

|

OR

What follows the operator is the feature to test for. Since conditional comments are exclusively a feature of Internet Explorer, IE is the only possible value. We can, however, add a version number in order to target a specific version or range of versions:

<!--[if lte IE 7]>Show this to IE versions 7 and below<![endif]-->

Fixing down-level revealed

Down-level revealed comments may work as they are, but as noted above they are invalid HTML. To standards-conscientious designers and developers like me this is unacceptable. Roger Johansson wrote about a solution in 2005. To summarize, it turns out that the solution is quite simple. Instead of using Microsoft’s suggested syntax of

<![if !IE]>Show this<![endif]>

use the equivalent but valid

<!--[if !IE]>-->Show this<!--<![endif]-->

All set.

Conclusion

I find that conditional comments are more elegant, reliable, and easier to use than scripted techniques for identifying browsers when it is necessary to create a separate style sheet for Internet Explorer. You can read more of the specifics in Microsoft’s documentation.