Semantic Shenanigans
When starting a new website project, most designers have the same thought, “I’m going to build this better than the last one.”
We want our project to be the representation of what CSS is capable of; we want our code to be clean and easy for others to read. But as time tells, adding new content or cool features eventually lands us with a coding mess of erratic class names. Creating semantic class names is tedious, especially when coding from scratch. Nicole Sullivan, well-known in the web development community, refers to class naming as ‘Classitis’ in her article “Our (CSS) Best Practices Are Killing Us” — sounds scary right?
It’s aggravating trying to come up with a name that fits the gray area of semantic class names. We wanted to help our customers (and ourselves!) by engaging in some research behind semantic class naming. We’ve had several discussions about semantic classes and have come up with a few techniques to better class naming.
One of our goals was making it easier to understand how we develop our themes. This is especially important when in a multi—class system because changes have to be made to the ‘right’ element. Additionally, we want your projects to be future proof. Both our themes and our customer projects are constantly being updated and changed, and we need to make sure these designs can evolve with the future without needing to change the class names. Lastly, semantic classes are reusable across the project, when we don’t put thought into the naming process we end up designing new classes with the same properties — redundancy alert! Semantically naming classes allows designer and developers to understand the look of that class and apply it throughout the project. Let’s start by understanding the word ‘semantic’.
What does semantic mean?
Most definitions of the word semantic come up as, “relating to meaning in language or logic.” Which helps us understand the basis behind semantic naming; it needs to be related to the reason you’re setting these property values. When classes are named after what their role is, it makes it easier for other developers to understand that class. However the ‘rules’ behind semantic class names have a gray area that is difficult to interpret.
Semantic class names should not be too narrow, but not too broad either. Somewhere right in the middle, the sweetspot! During our research we found numerous opinions about how to semantically name classes, from that we’ve selected the best tips & tricks to develop code that is legible and clean. Let’s look some of the most useful guidelines.
Property Values: only in very specific cases
The property value is the design you add to the element. An example of this in a grid system would be ‘span—8’ where in the class you only define property values for creating an content area that spans 8 columns. This is semantic in a grid layout when used for columns, because it describes exactly what the class is designed for. However if your start to apply other properties to that class, it would need another name. Or you could apply a secondary class.
Referring to property values can become unsemantic and not be future proof in other situations. For example developing the class names bold or light—blue for the company’s logo text. You’re tying that class to one specific property value, if you end up changing the values to dark—pink, your class name becomes a dud and you have to develop a new one all together. After that you have to go back and delete the class from the elements it is assigned to. Sounds annoying and tedious to us!
A name like ‘logo-color’ would work here, because the color can change without the name interfering.
We all need to be careful when using properties to name classes, because they need to evolve during projects. We want our classes to be future proof and able to develop with the project. Using property values for class names can be too narrow, making the use of that class inflexible. If we do decide to name classes this way, be sure that the name is broad enough in case the property changes over time. Semantic class names are evolving with the project and should accommodate new values. If the class name doesn’t fit anymore, it should be renamed or deleted from the project.
The Element’s Role
Using the role of the element to name classes can be very beneficial throughout projects. You can use it to help develop other classes or secondary classes specific to the theme. It can be legible to others when designers use the role to name classes for other sections of the website.
For instance, your header’s ‘main—title’ class sections your content. You could use it for other elements that are in the same sections such as ‘main—caption’ or ‘main—image’. This will help organize your theme and name elements specifically to the role they play in the design.
As an example, navigation menus and links often get the nav and nav—link classes. The class is specifically naming the roles the elements perform. It is easy for other developers to understand what properties are associated with the class. You want predictability when class naming and the element’s role is easily understood.
Here’s another tip for finding meaningful names: try to abstract the visual differences. Class names like BigOrangeHeader don’t work because it can’t change or evolve with the future, it is too narrow. However, a name of ‘highlight—header’ would work because it could become different colors, have a larger font—size, or a different background color.
Find the visual differences and abstract! If there are none, what is the point of creating that class?
Don’t create several classes with the same properties, it becomes apart of the coding spiderweb. To conclude, using the roles can be a great tool, but if the properties assigned to the class start diving into another role, you will need to develop a new class.
The ‘Right’ Element
While building the project, designers often find some elements needing a second class and only assigning it to a subset of the elements. As an example, to make an image inline with a paragraph, you need it to float. But you don’t need all images to float. For these situations you can create a class, such as ‘float—right’ or ‘float—left’ depending on which direction the image floats, and add it when needed without influencing any other image styles. If you decide you don’t want the element to float, just delete the class.
Be sure to only change the properties associated with the float for the floating class, nothing else because the name becomes unsemantic. You don’t want to change a property that is also designed for non-floating images. This leads to duplication because you would have to add those properties to a different class.
This technique works really well in a multi—class system, because it is specific to one property.
It should be used as a secondary name, because it can be used whenever necessary and doesn’t represent all the properties. It describes what the class is designed to do and can be used again when duplicating that look.
Wrap it up
To summarize, when creating class names, consider the role and use visuals differences as a reference. Also try making the names broad enough so they are able to evolve. Be careful with narrow classes, try to reserve them for working with secondary classes. There is a middle area that designers need to find. This, like everything else, gets easier with experience and practice. If you guys would like to access more information on this topic we’ve added some great articles for you to enjoy!
Voice Your Opinion
If you have any thoughts or feedback about this article, you can follow me on Twitter. You can also drop by our helpful forums page or leave a message on our Facebook page. If you know of other designers struggling with semantic naming feel free to share the article using any of our social media icons.
