Semantic Code is Simply Semantics

  •   Josiah Heigel

By Josiah Heigel

Are visually descriptive class names always wrong or can they too be semantic?

Over the past six months, I have been building a project infrastructure of reusable components to employ as a starting point for new project work. The CSS has been based largely upon the Inuit.css framework architected by Harry Roberts. Personally, I love his scaffolding, system and configuration because it provides a robust set of functions and tools, while not prescribing styles that I do not ultimately need or want.

Along with this framework, I created additional helper, font adjustment and branding classes relevant to my specific style and workflow. However, as I began to really think about the adjustments I was making, it seemed that I was not holding as tightly to industry standards as I should have been. I was committing the cardinal sin of using presentational classes in my CSS!
As you would likely expect, this truth cut to my very core and made me question my worth
as a web developer.

Yet, as I started to consider my heinous crime, I began to wonder if what I had done could really be that wrong? I get it. It is intuitive, helpful and even correct to name an object what it is in the context of the HTML on the page. A #site-footer is the footer of the site. A .button an actionable object on the site. Still, my questioning of this philosophy is highlighted in examining some common coding abstractions.

Hopefully, you’ve heard of the DRY (Don’t Repeat Yourself) principle or OOCSS (Object Oriented CSS). Essentially both relate to the theory of creating smaller pieces of reusable code so that (specifically speaking of CSS) our style sheets do not get bloated by duplicate selectors or properties. To the best of my ability, I employ these methodologies every time I style a website as well as attempting to do so in a semantically correct way. And herein lies the problem that I came across a couple days ago.

Semantically Delicious

According to our friend Merriam Webster, the definition of semantics is as follows:

"the meaning or relationship of meanings of a sign or set of signs; the language used (as in advertising or political propaganda) to achieve a desired effect on an audience especially through the use of words with novel or dual meanings."

Or as my Google search puts it:

the meaning of a word, phrase, sentence, or text.

Therefore, semantically correct code, is code written with a particular meaning or purpose that often times has a desired audience in mind. If I apply this to my style sheets along with the principles outlined above, I will try to create class names and selectors that are easy for my peers to follow and intuitively piece together the wider picture of the website.

The Semi-Presentational Class

My plight arises with this question: What if presentational class names are semantic? I know you may be thinking that’s a ridiculous statement, but hear me out. Let’s look at something as simple as the font color. The services page of our website provides a good example for us to quickly pick apart.

Content image

Example - Our Services

As you scroll down the page, you will notice orange headers in the main content section, white headers in the teal section followed by dark gray headers in the extended footer. In this instance, all of those headers are the exact same pixel size which I’ve made them equivalent to an h4 tag.

For this example I need an h4 with 3 different colors (the main h4 color will always be #585351 /* dark gray */). The other colors could potentially have the following class names and properties.

Content Image

Example 1

This is semantically correct, but if a new developer comes into this project it will take a couple seconds to figure out what properties are specified by --callout and --highlighted. Finally, what about the paragraphs with white text? The body color is not white, so I would
need to create a new style, which isn’t very DRY.
I could modify the above styles to be
something different.

Content Image

Example 2

Although now, we’re starting to lose some semantic meaning, because text is so broad and it still doesn’t clarify anything for a new developer ramping up on the project. Now, I want to be careful, because what I am about to say is based off of the Inuit.css framework and credit should be given where credit is due, but a disclaimer is necessary. I want to clarify that the following does not necessarily reflect the views and opinions of the Inuit.css framework as a whole. Why not make these names semi-presentational?

Content Image

Example 3

I realize that I am going against the grain here, but isn’t this the best of both worlds? First, the class names define the text associated with each class to be branded a specific color. Second, a new developer on the project has some context of what is happening and what property is being affected. Third, my code is as DRY as I believe that I can make it, because I’m shooting for small reusable pieces. Finally, when I’m coding a new site and I know the colors and class names available for a given project, the speed at which I can produce markup is increased substantially since all I need to know is adding specific properties via their respective classes.

I completely see the need for semantically correct code and I’m not arguing against that as a general rule. What I am arguing against is the blanket statement that presentational styles should be avoided completely. I feel that this example has merit and it has worked well for me in the past, however let me know what you think! 


Header photo by Sebastien Wiertz