Monday, September 28, 2009

Naming schemes

Here is a list of minor things about the naming schemes of CSS classes, files and URLs which I've accumulated over the years. Some may be outdated, but nonetheless they were issues found over the course of the last decade of web development:

  1. Back in the Netscape days, some of the versions did not play well with underscores. This meant that underscores were specifically avoided to prevent CSS issues associated with Gecko browsers. This may not be an issue anymore but it is still avoided for SEO purposes.
    • GOOD: <A CLASS="db-item">
    • BAD: <A CLASS="db_item">
  2. Search engine optimization methods suggest using hyphens over underscores for both CSS classes and files.
  3. When CSS classes have numbers immediately proceeding hyphens, the Javascript in some browsers will error. This issue still exists in some IE browsers. Avoid numbers after hyphens!
    • GOOD: <A CLASS="db-item1">
    • BAD: <A CLASS="db-1">
  4. In the past, older, legacy servers weren't able to differentiate upper and lower case letters. They would call upon the same file regardless of case. This problem has been “fixed” and therefore, it opens up the possibility of having two different files named “test.jpg” and “Test.jpg”. I highly recommend filenames and URLs containing only lower case. Domains can never be case-sensitive, so why complicate this procedure by introducing capital letters into the URL? Does it make things easier for a user to remember the word AND casing?
  5. Classes as contextual information. Naming classes based on a visual aspect “middle-column” has always been frowned upon because CSS is supposed to separate presentation information from the HTML. Instead, class names that describe the component or information works far better.
    • GOOD: "breadcrumb" or "main-content"
    • BAD: "left-column" or "font-size12"

When it comes to web development on large-scale projects, I firmly believe in simplicity and consistency. When a decision has been made on the naming schemes, however wrong it may be, it's best to stick with it. This is a more pragmatic approach because it addresses several things:

  1. Developers will always need to work within some sort of limitation.
  2. As a developer, you probably weren't brought onto the project to re-code existing work.

And to be completely frank, if ever you *are* brought onto a large-scale project, the naming scheme should be the least of your concerns.

No comments:

Post a Comment