In the first part of this article, I discussed how semantics in markup have to do with the literal meaning of an element in relation to its content. The contemporary ideal is to move away from describing content in presentational terms and to describe them in terms that are more meaningful.
For some years I worked for the Microsoft Network (MSN). This was around the time that Internet Explorer 3.0 for Windows became available. Interestingly, IE 3.0 had the most advanced CSS support for a commercial browser during that time, and working for MSN—which was a closed network at that time —I had to use CSS 1 to style aspects of the pages I was working on. Of course, in those days I knew nothing of Web Standards, or document trees, or thinking beyond presentation for the computer screen.
So, when it came to naming classes, I would typically name the class in accordance with how the style would look rather than what the relationship to the element contents was. That resulted in class names such as the following:
.red .12pointTimes .bigText
Of course, these are all presentational descriptions! Although perfectly functional in that environment, this causes more harm than good in today's methodology (and yes, we used points for screen measurements—something we never do today, but hey, what did we know?)
With the growing use of CSS 2.0 for layouts, the creation of meaningful IDs has also become a critical issue. The goal is to relate the ID name as much to the content that it's describing as possible. What's interesting is that we're beginning to see conventions arise for naming specific sections of a document such as the following:
#content #nav #footer
Again, the avoidance of presentational names becomes helpful as we end up describing the document more clearly. A division described as #content makes far more sense than a division named more for its presentation, such as #centercolumn.