HTML and CSS are arguably two of the easiest languages to learn and are usually the first two that total beginners pick up. You learn the languages and make a website that looks pretty decent in a minimal amount of time. Other than the cascading nature of CSS, it’s fairly loose in structure and unlike other languages it won’t scream at you when you screw up the syntax. But, as your original website grows in complexity, it’s easy for that beginning CSS to start looking like spaghetti code. It gets to a point where you have 10 different classes that override or repeat each other and the frustration of untangling your original code begins. So then where’s the best place to start and what’s the best way to structure your CSS code? Here are some best practices that I’ve come across that have been “ah ha!” moments for me when I was starting out.

Think of CSS classes like adjectives

I was initially taught to think of CSS classes as “names” for the elements on my HTML.

Following that train of thought let’s consider this example:

In this example, we’re naming each element differently and then just applying styling to each as needed.

.box-1 {

background-color: blue;

height: 100px;

width: 100px;

} .box-2 {

background-color: green;

height: 100px;

width: 200px;

} .box-3 {

background-color: blue;

height: 100px;

width: 100px;

}

While this is a great start, this train of thought quickly becomes confusing as your project scales. Imagine if at some point in the future we needed to add ten more boxes. While classes do directly tie together styling and markup, it isn’t a one to one relationship. Instead of thinking of them as names, think of CSS classes as adjectives that are mini packets of code that describe specific attributes. Instead of directly connecting CSS classes to elements, we can use classes as a way to describe how elements are similar or unique in relation to one another.

We can create a class that describes how the elements are similar to other. A class box that describes a similar trait for all boxes shown.

.box {

height: 100px;

}

Now we can describe how they differ from one another. The immediate traits that should jump out are the varying widths and colors of the elements. We can write this in CSS like:

.small {

background-color: blue;

width: 100px;

} .large {

background-color: green;

width: 200px;

}

The great thing about this technique is that it naturally leads to a convention of naming a class after the styling it applies. For instance, using “primary-color” as a class name over “blue”. You can then go back and use these modular bits of CSS in the future should you ever need to create more boxes. While this definitely won’t happen in all cases, it’s a good thing to think about if you find yourself applying the same property to multiple elements.

Don’t Rely too Heavily on Frameworks

While CSS frameworks provide a great way to quickly prototype, they can also lead to an overly-complicated solution to a very easy problem. It’s important to realize that a grid system isn’t the only way to implement a responsive layout or element. While frameworks are great, using them can sometimes be like using a bulldozer to plant a flower. The other day a co-worker of mine told me he wanted to have something sit in the center of the screen, be full width on mobile but stop at a certain point on desktop, and it had to be responsive in between the two. The solution he showed me looked like:

HTML:

<div class="row">

<div class="show-for-medium-up md-1"></div>

<div class="sm-12 md-10">

<img src="path/to/image">

</div>

<div class="show-for-medium-up md-1"></div>

</div>

While this definitely gets the job done, there are extra divs in the markup that are only used as spacers. In addition, there’s no fine-grained control over the final width of the image without changing the number of columns that the div takes up. The solution is technically correct and gets the job done, but at first glance it’s difficult to get an immediate feel for what it does. I proposed the alternative solution of:

HTML:

<img src="path/to/image">

CSS:

img {

margin: 0 auto;

max-width: 600px;

width: 100%;

}

Here, it’s immediately apparent that the image needs to be full-width, and max out at 600px. The only magic is the auto-centering margin. If you didn’t know that applying 0 auto automatically centers relative or statically positioned elements, this blog post probably just changed your life. If you find yourself placing framework classes on elements you’ll never see, or if you’re using HTML elements for styling, you might be running into this issue.

Make Every Line Matter

A really good way to test that you’re not repeating yourself or using CSS properties that you don’t need is to use the handy dandy developer tools in your browser of choice.

Chrome CSS Style Inspector Tool

If you click on an HTML element within any inspector tool you’ll be shown all the CSS properties that are applied to that element. You’ll also be shown some checkboxes next to those properties when you hover your cursor over them, you can turn on or turn off that particular style by checking or unchecking the box. Since I didn’t really understand every single property that I was applying when I started out, turning off styles and seeing the element immediate affected by the change was extremely helpful. The ideal end goal is to have almost every “uncheck” change the target element. Removing unnecessary properties makes your CSS much more manageable and readable.

While these most definitely aren’t all the best practices they are some of the common ones that have helped me in the past. I hope they can help you in your future endeavors in CSS!