Let’s Talk About CSS Naming (pt 1)


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




Imagine for a moment that your mom wanted you and your friends to make a cake. The most obvious way to do this would be to carefully listen to the instructions, and then go off by yourselves to make the cake. After you’ve finished, you return to your mom and show the results.

Sure, that is a method that could work. But due to its non-communicative nature, things might go wrong. What if you present the final cake, but your mom realizes that she wanted brown sugar instead of chocolate flakes as the third layer of the cake? It would be very costly to make those changes.

A better way – an agile way to carry out this mission would be to break the making of the cake into smaller steps. Bite-sized pieces that you can frequently show to your mom. For example, in hour one you build up the first layer of the cake. Then you show this to your mom and see what she thinks. If she likes it, then she will tell you to proceed. If not, she can suggest changes. Due to your mom seeing all the progress as the cake is being made, changes are much easier to implement. If you do need to make changes, you can simply update one component instead of the entire cake.

This is the general idea behind agile development, but it’s a very, very shallow introduction.

The main idea here is that those developing the project adhere to short-term goals. These are usually called stories. Engineers are assigned specific tasks for them to complete. After assignment, they go and enter what is known as a “sprint”. This means that they will try and implement the specific story, and report back once it’s complete. These sprints usually last anywhere from two weeks to a month. On top of all of this, a daily meeting, called a scrum, is held very quickly in order to assess progress. These scrums can help identify problems that may be holding the implementation back. At the very end of a sprint, the engineers gather and create new stories that need to be completed in a following sprint. This process continues until the final product is created.

During the initial phase of fleshing out stories, engineers have to fully understand the purpose of their application. This involved creating various user profiles that will represent potential categories of real users. A power user is going to have much more intricate knowledge of your product than a regular person. This means the engineers have to create two user profiles, one for each. There are many potential user profiles, and the engineering team should try to cover as much as possible.

Once user profiles are set up, the team can begin throwing out stories for each type of user. For example, as a power user, I want to have an advanced configurations setting so that I can customize the application further. These types of stories have to be written out for each feature of the app. Once the stories behind each feature are written, the engineers will understand their application a whole lot more.

Once stories are fleshed out, the sprinting begins. Teams meet each day in the morning for a quick meeting, or a “scrum”. These scrum sessions begin with each engineer stating the accomplishments of the day before, and then reporting their tasks for that day. Engineers will also report any blockers that they have encountered while implementing a story. Any potential confusions, bugs, or other problems that may arise during development. The meetings try to move as quick as possible, and usually never go over fifteen minutes.

Once the scrum session is over, the engineers return to their tasks of implementing the story for that sprint.

These sprint sessions usually last a short period of time. At the very end of a sprint, the team will assess the development process of the application, and decide on new stories. They will then product more sprints to try and implement those stories.

The cycle goes on until the final product is produced. It is easy to tell that such a process has many advantages over the traditional method of “assign and forget”. Agile is not a methodology, but simply a different way of approaching a problem. Break down large problems, provide constant feedback for each chunk of feature, and organize in a way that optimizes production time and efficiency. Of course, it does have its flaws. Their are countless companies that incorrectly implement scrum, or abuse it with their employees. On the other hand, agile becomes a valuable asset to any team willing to stay true to the process, and provides a tactical way of tackling an impossible task.