First, some basic definitions: classes and IDs are two types of selectors that are used to designate HTML elements to which properties and values are applied. The main difference between a class and an ID is that a class targets multiple elements, and an ID targets one element.
Second, the methodology for applying class and ID selectors to HTML: I'll start with going through the class methodology, and then come back to ID. After the name of the element in an HTML tag, add class="text", with the name of the class substituted for "text". Here's an example of the HTML syntax.
<p class="text"> Lorem Ipsum etc.. </p>
The Lorem Ipsum text will have the property/value attributes defined by the "text" class.
In your CSS stylesheet, classes are defined with a period, followed by the class name, then the property and value of the class in squiggly brackets, followed by a semicolon.
.text {
property:value;
}
The method for defining and applying IDs is essentially the same as class, with ID replacing class in the HTML tag, and a hash (#) replacing the period in the CSS. An example is given below.
<p id="text"> Lorem Ipsum etc.. </p>
#text {
property:value;
}
Below is a screen shot taken from the Mozilla's Developer Network's Selector page, demonstrating the HTML and CSS class and ID methodology.
Now that we've defined class and ID, and shown how to use them in HTML and CSS, let's talk about best practices. First, many CSS tutorials say that you should ideally use classes much more frequently than IDs, because classes can be applied to many elements and IDs to only one. This will save time and make your CSS stylesheets cleaner, more organized, and more succinct. Regarding class names, don't use Camel Case, and do use hyphens or underscores.
There are also some advanced CSS best-practice concepts that I'm mostly familiar with from tutorials and searching around on the web, and haven't (yet) had much experience with in practice. These include CSS abstractions, such as SASS and LESS, and design patterns, such as Atomic, OOCSS (object-oriented CSS), BEM (Block Element Modifier), and SMACSS. CSS abstractions sound interesting to me, but my knowledge is pretty basic right now: It seems like they apply the "class" concept more broadly yet simply, creating a new stylesheet syntax that allows the author to define functions. I'm not sure exactly what this means right now, and I hope that as I get more familiar with Ruby and Rails, I can maybe get familar with CSS abstractions such as SASS or Compass.
I did play around with the Atomic CSS design pattern, but the results were not great for me. I see the value of the design pattern, which as I understand it can be loosely defined as follows: each class only has one property:value pair, you apply many classes to each element, and you follow a naming convention methodology to simplify your CSS classes. You end up with HTML elements with a ton of classes, but you have the benefit of easily replicating a particular property:value throughout a page or site. I like the idea, but I think that effectively applying this design pattern requires a familiarity and a certain amount of skill with CSS and website design in general that I am currently lacking. I'm still getting a handle on basic positioning of my infant website pages, and I think the "you gotta learn to crawl before you can walk" idiom is applicable here. Basic CSS is still a pretty painful process for me, and I don't think I'm ready to apply advanced organizational concepts like Atomic when I don't have a handle on the basics yet.
The other design patterns (OOCSS, BEM, SMACSS) remain little more to me than acronyms, at this point. I know that they apply to best-practice theory in CSS, more specifically to organizing and streamlining your CSS, but talking about them would open up way too many rabbit holes for this blog entry. So I'll leave you with just the links given above, and you can explore them if you like.
In sum, the little bit that I can say with any confidence regarding CSS best practice is as follows: classes are preferable over ids; there are a number of next-level organizational concepts that empower the designer to take class-based organization to even higher places. Perhaps sometime down the line I'll make another post when I'm working towards those higher levels. But for now, I've got plenty of work to do on the ground floor.