It can bring you to an air-guitar celebrating high, or an over-the-top-face-palming low. When I started my web development journey, CSS was just as confusing as the programming language I was trying to learn. It was a pain to style those messy elements into the beautiful layout that you had popping up in your head. Some of the confusion did go away eventually, but there was still another issue with CSS that stayed. It wasn’t CSS attributes, or even how to properly use them. After all, those questions could simply be answered with a quick google search. The problem was naming.
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
For a non-developer, the problem seems so silly. Naming things? How difficult can that be? It does seem quite trivial at first from an outsider’s perspective, but any developers who have even begun to build projects, regardless of size, will tell you that naming is something that needs to be taken with more than just a grain of salt. It can be the deciding factor in your code’s readability and consequently, its maintainability. Conversely, bad naming habits will also make others less receptive to reading your code.
This practice carries over to CSS as well, specifically those CSS class names. When we begin to style our webpages, we usually create a separate CSS file, declare the class names on there, and then import that stylesheet over to our html file. We then utilize those class names and id’s on our html elements. Seems pretty simple right? For small, personal projects with very little html, you probably don’t have to worry too much about how the classes are named. A couple chunks of css code with vague naming won’t cause a lot of readability issues.
When web applications grow however, and the amount of html components begin to increase, developers need to focus on the way they name their classes. They need to begin to follow good CSS naming practices.
There are many conventions out there trying to solve the problem of organizing CSS markup. Some of these are explicit tools that need to be used, while others are simply naming conventions to be followed. Let’s take a look at a few.
CSS Pre-processors (SASS / LESS)
CSS pre-processors can be thought of as a tool that “extends” vanilla CSS functionality. It provides a developer with the option to create and store CSS variables, provide mixins that can be re-used throughout the CSS files, and a host of other features that help streamline the styling process. The modularization of the CSS also leads to better organized code and greater project maintainability. When using a pre-processor like SASS, you’ll also need a tool to compile the file into its CSS counterpart. This is usually done with a bundling tool like Webpack or Gulp.
OOCSS (Object Orientated CSS)
OOCSS is a naming guideline with two core principles. The first is to “separate the structure from the skin”. What this means is that you wouldn’t have a div class called “tv-box-container”. Instead, you’d separate each component in your html by giving them a different name that is descriptive of what they are. You’d name a div with “tv”, and perhaps the images inside are named as “img”. By doing so, your override the need to reference the actual element itself in CSS, which causes problems when you need to re-use certain styles.
The second guideline is to “separate the container and the content”. Instead of referencing an element using “.tv-container h2”, you’d ideally give that particular h2 a class of its own. By doing so, you can assure that all h2’s without that style look the same, and any class that does need the styling can simply add the specific class name.
BEM (Block Element Modifiers)
BEM styling brought a lot of sanity to larger projects that have a lot of different html components. When using BEM conventions, your div might be named “tv”, while your inner div would be named “tv__retro”. If you had any other nested divs inside of “tv__retro”, they would start with the name “retro__” and reference a description of what that element contains after the underscores. By following this convention, you are essentially organizing your blocks of html into very particular styles, minimizing the chance of conflicts between different styles between a large amount of CSS files.
By following the BEM convention, your html components became more re-usable, since the styles that they depend on contain unique class names and references.
More in part 2