CSS Adventures: Classes, IDs and specificity

As a front-end web developer, in the present day:

  • we’re looking at modular, reusable CSS,
  • it’s almost a must in every set of code guidelines to reserve IDs for JavaScript hooks, or to only use them when absolutely necessary,
  • and we assume that most web developers are writing modular and reusable code.

However, I’ve had a few questions from junior web developers who are lost or unable to understand the concept of modular CSS (not to mention are still using IDs more than once on the page). Modern guidelines can confuse developers who are new to coding, or even junior developers who know how to code but do not keep up with industry standards. Shocking as it may seem, it does happen.

I learned about modular CSS back in 2010, and even then, it was probably not considered a ‘new’ concept anymore. I wish I had written about my learning experiences back then. This sort of dumbed-down post is for the ‘newbies’ and takes things back to a super basic level. If you’re at that level, it’s OK. It’s OK to ask questions. If there is one thing I have learned in my career it’s that you should always ask questions because you will always learn, and no one will think you are stupid if you are genuinely curious or want to know how something works. :)

I was going to write a more advanced post today, but something compelled me to write this. O:)

What is a class, and what is an ID?

I wrote an article about this back in 2010, and it sat on my blog for a while. I removed it because I thought that it was an easy thing that everyone knew. That wasn’t really the case!

IDs can only be used once

Think of an ID as a unique identifier. Like a name or a phone number. On your website, elements with IDs should generally only be used once. Like a header, sidebar or footer. It makes sense for these elements to have IDs.

<div id="header"></div>
<div id="sidebar"></div>
<div id="footer"></div>

Classes can be used many times

Classes can be used for elements that are repeated on the page. You don’t always need to add a class – for example, there is no need to add a class to every paragraph in a blog post, but it might make sense to apply a class to the outer element of each blog post.

<div class="blog-post">
...
</div>
<div class="blog-post">
...
</div>
<div class="blog-post">
...
</div>

CSS = Cascading Style Sheet

CSS works by cascading. I’m genuinely surprised how many people don’t actually know this. When writing CSS, anything further down your stylesheet will override what is earlier on in your stylesheet.

If you wrote the following, the second line would take precedence over the first and your background would be #eee.

.blog-post {
    background: #ccc;
    background: #eee;
}

But no! We shouldn’t use IDs anymore! (!!!!!)

OK, so somewhere along the line it was decided that classes should be used over IDs because of specificity issues. But what the heck is specificity?

Some ways we style CSS are more ‘expensive’, and IDs happen to be very expensive. They cost a lot. Which of these do you think will take precedence?

#blog-post {
   background: #ccc;
}

.blog-post {
   background: #eee;
}

That’s right, the ID – #blog-post. Our background will be #ccc.

But I still don’t get this specificity thing…

That’s OK, I’m glad you asked. Consider the following example of HTML:

<div id="header">
    <div class="header-blurb">
        <p>This is a paragraph.</p>
        <p>This is another paragraph.</p>
    </div>
</div>

Consider the following CSS:

#header p {
    font-family: Georgia;
}

.header-blurb p {
    font-family: Arial;
}

Even though the second rule was further in the cascade, the element with the ID selector in front has overruled. Our paragraph text will be in Georgia, and not Arial.

Had our element with the name header been written as a class instead of an ID, our paragraph text would have been in Arial.

This is just a simple example, but as more and more IDs are used in your code, there is the potential for your CSS to get more tangled as you try to override various rules. As IDs can be used only once, this means that a few minutes later we might have something like this:

#content p {
    font-family: Georgia;
}

#homepage #content .content-blurb p {
    font-family: Arial;
}

You can imagine what it may look like if this chain continues.

What does this have to do with modular and reusable CSS?

If you consider the look and feel of a web page, there are some components that might be repeated. A blog entry has the same structure and styling as multiple post excerpts appear down the page. Sidebar components generally have the same styling in their titles and text. Think of parts of your website as various LEGO pieces. Some will be the same, and you may have a lot more of one type of block compared to another type.

This is where we think of classes as identifiers for these blocks. blog-post and sidebar-widget-title are possible class names that can happily be re-used in our HTML, and styled with a minimum amount of CSS.

Classes can be re-used, so they are a good option in the case that we need to move things around our website. If we use classes as much as possible, we can move these blocks around freely. Classes hold the same weight of specificity, so we don’t need to worry about writing CSS like this:

#sidebar-social-icons a {
   ...
}

Instead, we can do something like this:

.sidebar-widget { /* previously #sidebar-social-icons */
   ...
}

.sidebar-social-icon { /* previously #sidebar-social-icons a */
   ...
}

See what I’ve done there? I’ve made the class names more generic and kept CSS on one level, so that if we were to move things around, we would have less of a problem.

Further reading

I have just stripped down to the basics, but here are some awesome links to illustrate specificity in perhaps a better and clearer way. I feel like this may be new or puzzling to some of my readers who are just starting out. But I hope they help you.

CSS Specificity And Inheritance was published in 2010 and was indeed the first article I read about CSS specificity. Highly recommended! :D

Other reads below:

Let me know if you think any other links should be added. :)

Comments on this post

Great informative post! You made it so easy to understand. :) Have you considered writing an e-book about CSS? I feel like I learned a lot from your posts. Keep it up!

Thanks Kristine! I was worried it would sound too mumbo-jumbo but I am glad it made sense to you. I try to write in my own ‘conversational’ style because I can explain things better that way and I am sure people have a better time understanding it that way compared to technical articles.

I haven’t considered writing an e-book, mainly because I don’t really have a coherent set of topics. I generally like to write about semantics, but writing these posts is just a way of me extending my learning about anything web development related, out to other people. A lot of what I like to write about is the really niche, almost trivial stuff. Hopefully you (and other people who are interested) can follow the web development category for now. :) I guess I’m not really taking the instructional e-book route so I am not keen on writing a ‘how-to’, but if there is anything you happen to be curious about that you would like to hear my stance on – give me a shout. :D

This is really great and I love the way it is written. I am sure it is going to help anyone who might be a bit confused by this.

When writing CSS, anything further down your stylesheet will override what is earlier on in your stylesheet.

Haha. I fail. I thought anything that was higher up was bigger priority. Thank you for pointing this out. :D

Haha, at least you learned something! :D :D