Design and Inspiration

I’ve recently read that the standard naming convention for variables in JavaScript is CamelCase. That is, putting together capitalized words without spaces. Normally, when people say camel case they really mean lower camelCase where the first letter of the name is lower case and reserve the term PascalCase for “upper camel case” where the first letter of every word is capitalized.

camelCase is the de facto standard in JavaScript and preferred among other programming languages as well, but I don’t come across is that much in the design world where we mainly work with HTML and CSS.

For CSS naming of IDs and classes, using hyphens or underscores to separate words in a name is by far more common:

top-nav-header or top_nav_header as opposed to topNavHeader.

Personally I’ve always preferred the underscore naming convention. Not only for CSS, but for URLs, filenames, etc… However after some digging around about standardized naming conventions I’ve come to the conclusion that from now on I’ll be using the following model:

• hyphen-naming-convention for HTML, CSS, and URL names.
• underscore_naming_convention for file names.
• camelCase for JavaScript.

There really is no preferred method for CSS like there is for JavaScript. I see underscore and hyphen usage equally on the web. Some say hyphens are more legible, but I think that’s a matter of preference too. The one argument that I think makes sense is that it’s quicker to write a hyphen which only requires one keystroke (hyphen) vs. an underscore which requires two keystrokes (shift + hyphen). That might seem like a fraction of a nanosecond difference at face value, but it adds up over time, especially when you’re designing a new template from scratch!

As for URL naming schemes, I’ve read some interesting stuff about the way Google (and some other search engines possibly?) handle web pages named with a hyphen vs. and underscore. Apparently Google views hyphenated URLs as separate words, so if you had a page called “george-is-the-best.html” that page would show up in search for “george”, “best”, or “george is the best”. However if that same page was named “george_is_the_best.html” it would be treated as one long word and only show up in searches for “george is the best”. Crazy, huh? I think that’s more than enough reason to keep to naming pages with hyphens instead of underscores!

As for file names, these are tricky beasts. That “New Year’s 2010″ image on your desktop is named and read just fine like that on your computer. But try accessing that file from terminal (or command prompt if that’s your flavor =)P ) and it sure is annoying. And on the web, that’s not even legal! I didn’t come across any specific article that talked about hyphens vs. underscores for file names, but from personal experience I’ve never had trouble using underscores and see no reason to switch that naming convention now.

The key is to develop a standard naming convention that works for you and is acceptable to most others and stick to it.

Further Reading & Reference:

Matt Cutts – Dashes vs. Underscores

At work we maintain three different versions of our site — (1) production or live, (2) staging, and (3) development. This is standard practice for professionally run sites because it gives developers a chance to test changes and new features to the site before showing it to the public. Ideally, major changes or redesigns are created on the dev site and then pushed to staging for testing. Aside from the new changes, staging should be a mirror copy of your live site, which is the only site the end user sees when they visit.

Maintaining different sites and several servers can be a costly venture for the lone developer, but fortunately, with some tweaking, we can create our very own development environment on a standard $10/month virtual host. Here’s how I set mine up for this very site.

Things you’ll need:

1. An apache server.
2. mod_rewrite module installed.
3. Access to your .htaccess file and the ability to modify it.
4. Ability to create subdomains.

The .htaccess file is a hidden file located in your public_html or www folder. You can also have a separate .htaccess file for subfolders, but for the purposes of creating our virtual sites, we’ll only tweak the one located in the main folder.

1. First we’ll create our sites as individual folders in the main directory. Call them what you want, but I named mine (1) live, (2) staging, and (3) dev.

I’m assuming you’re starting from scratch with an empty server like I was. If not, you may have to move your current content into the newly created live folder (whatever is in this folder will be visible to the rest of the world).

2. Create your staging and dev subdomains and direct them to their corresponding folders. Don’t worry about your live folder for now. In the end we’ll point anything accessed using the main www url to that folder.

e.g. http://dev.yourdomain.com points to http://www.yourdomain.com/dev

3. Check the view hidden files option in your ftp client and navigate to your public_html or www folder and open up .htaccess. Here’s where the magic really happens.

Apache has the ability to rewrite and redirect URLs using the mod_rewrite module. I won’t go into detail here about how it works, but basically you can do some cool stuff like rewriting long URLs such as http://www.mysports.com/basketball.php?section=stats&year=2010&team=knicks to http://www.mysports.com/basketball/stats/2010/knicks. If you’re interested in delving deeper into the subject, check out the Further Reading & Reference below for more info.

For our purposes we’ll be using this code:

Options +FollowSymlinks
RewriteEngine on
#
# REDIRECTS
#
# Add www in front of all URLs except subdomains
#
RewriteCond %{HTTP_HOST} ^mydomain\.com$
RewriteRule ^(.*)$ http://www.mydomain.com/$1 [R=301,L]
RewriteRule ^$ /index.html
#
# Add forward slash at end of www URLs
#
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.mydomain\.com$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\..+$
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://www.mydomain.com/$1/ [R=301,L]
#
# Forward requests to live folder
#
RewriteCond %{HTTP_HOST} ^www\.mydomain\.com$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/live/
RewriteRule ^(.*)$ /live/$1

That’s the exact code I’m currently using for this site and will probably work for you. Simply edit “mydomain” and “live” with your domain name and whatever you decided to call your live folder in Step 1 and you’re all set.

Make sure you have

Options +FollowSymlinks
RewriteEngine on

otherwise nothing will work. Those two lines are necessary for any redirect or rewrite rules you create in general.

Notes on Usage:

Using the above code, whenever someone visits http://yourdomain.com or http://www.yourdomain.com they’ll be redirected to your “live” folder without knowing. If they entered http://yourdomain.com then the URL will be changed to http://www.yourdomain.com. You can tweak the www rule if you don’t like it, but it’s good to stay consistent about what the standard URL of your site is for SEO purposes.

Further, a forward slash (“/”) will be added to all the URLs on your live site. I added this rule because I was having trouble with my site recognizing some URLs as directories and therefore failing to look for “index.html” inside of them (technically, folder paths are marked with a trailing “/”, so http://www.domain.com/dir was being seen as as a missing page instead of a folder with index.php inside of it). You may not need this rule at all.

Subdomain URLs remain untouched so http://dev.yourdomain.com forwarded to http://www.yourdomain.com/dev without the URL changing. This is important because it maintains the structure of your relative links for the site. If the URL was redirected AND changed to http://www.yourdomain.com/dev in the browser, then public_html or www becomes your root folder for the dev site instead of /dev.

As a result, if you referenced /css/styles.css in one of your dev files then it would look in http://yourdomain.com/css/styles.css instead of http://yourdomain.com/dev/css/styles.css. You could easily reference the file by writing ../css/styles.css or /dev/css/styles.css instead, but then you’d have to edit the link when you moved it to your live folder. The whole purpose of setting up separate sites is so that you can make changes on a mirror site for testing and then easily copy the changed files over without having to edit them.

Now you have three separate sites on the same domain independent of each other for development and testing purposes. That’s all there is to it!

Further Reading & Reference:

Corz.org – .htaccess tips and tricks…

My Digital Life
Add Trailing Slash to the End of the URL with .htaccess Rewrite Rules

TheSizeWizard.com
How to Redirect URLs from Your Root Domain to the WWW Subdomain and Vice Versa

StackOverflow.com

ServerFault.com

The first time I noticed this was on www.newegg.com a few years back. Their text links were black with a slate blue underline that when hovered over turned orange. I thought that was a pretty easy and neat way to add some flair to your usual mono-colored text link. The styling is accomplished by using border-bottom instead of the usual text-decoration property.

Usually the underline in links are styled using text-decoration. Using this method, the underline of a link would be the same as the font color.

a {
    text-decoration: underline;
    color: orange;
}

The above would produce an orange link underlined in orange.

By using border-bottom and setting text-decoration: none; however, we can create a link with black text and an orange underline.

a {
    text-decoration: none;
    border-bottom: 1px solid orange;
}

Having the underline change color on hover is easy too:

a:hover {
    text-decoration: none;
    border-bottom: 1px solid green;
}

You can also adjust the distance between the bottom border and text and border width using padding-bottom and adjusting bottom-border (example):

a {
    text-decoration: none;
    border-bottom: 3px solid orange;
    padding-bottom: 5px;
}

The devastation in Haiti is colossal and they desperately need your help. And help you should! Since we can’t all jump on a plane fly out to Haiti ourselves, the next best thing you can possibly do is donate money. But wait! Don’t you want to make sure every penny you donate is put to good use? Of course you do. Before you write that check, take some time to investigate the charity that you’re giving to. Scam charities aside, while they may all have the best of intentions, some are just more efficient at using donation dollars than others.

Wyclef Jean’s Yele charity for instance may be doing a great job at raising money through text messaging, but are they the best people to handle that money in the end? Even America’s favorite go to charity, the Red Cross, may not be the best charity to handle your money.

Check out Charity Navigator for stats about various charities committed to helping out the survivors of the earthquake in Haiti. This place is a great resource to see how efficient various charities actually are and to find out exactly how they plan to spend your donated dollars. Whether it’s for the people in Haiti or some other just cause, always take the time to investigate a charity before donating to them and go with the one with the proven track record of assistance.

With that said, what are you waiting for? Go! Donate Now!