Code Icon

Wait. I should use a different selector for CSS and JavaScript?

Published on

You’ve done it, I’ve done it, just about everyone has done it. After all, it was the way I was taught when I first learned JavaScript && jQuery.

You have an element, you give it a class for styling, but you also use that class as a selector in your JavaScript.

It works. All is well, right?


What if, down the road, that element’s class changes due to some styling issues? Now your JavaScript is also broken.

What if, down the road, you re-design the site using new CSS selectors. Now your JavaScript, that maybe you planned to re-use, is broken.

Okay, you update the class names in your JavaScript too. But…now that’s extra work you didn’t anticipate. And, what if you miss one here or there? It could lead to errors on any number of pages.

See where I’m going with this?

Separation of Concerns

Honestly, I never even really thought about it until I came across this article on CSS-Tricks.

The idea is separation of concerns, right? We want our CSS selectors to deal with CSS stuffs and our JavaScript selectors to deal with JavaScript stuffs. Whenever those two mingle, things can get a little complex.

For example, I recently started a new job. When working through a page template, I found a class that I deemed unnecessary because it was just there. Maybe it was part of an old iteration, right?

Well…turns out that class name was important as a JavaScript selector. So, it was necessary after all.

The concerns were separated, yes, as the class had no styling value. However, it was named just like a styling class. Same naming convention. There was nothing there to differentiate it.

That is just one example in the endless amount of possible problems that could arise.

Selector Examples

There are many different examples out there about how to deal with this problem. One example that’s interesting, as given in the CSS-Tricks article, is to use data attributes.

See the Pen Data JS Hook Example by Kyle Hawk (@Krazyhawk) on CodePen.

This solves our problem. Our class name now only deals with CSS, and we have a custom, future proof, attribute name whose whole purpose is to be a hook for JavaScript.

I quite like this approach as I find myself using data attributes mostly for dynamic data anyway. It seems like an appropriate fit to me.

Of course, there is another popular way that seems to be emerging. If you scroll down to the comments of the CSS-Tricks article, you will notice it. The idea is that it’s okay to use class names, but prefix them with something like “js-” in order to signify what they are going to be used for.

See the Pen JS Selector Class Name Prefixed by Kyle Hawk (@Krazyhawk) on CodePen.

Using a naming convention such as this helps separate our concerns. We have CSS class names for CSS, and then JavaScript class names for JavaScript.

With one look, you are able to determine if that class name is for styling, or a JavaScript hook.

A little thing like that certainly goes a long way.

Why Do This?

Right about now you may be thinking to yourself, “Well I know this part of the site isn’t going to change, so it’ll be fine” or “I’m the only one working on this project, so it doesn’t matter”.

Well, you don’t know the definite answer to either of those.

Whenever I code a website I always think to myself, “oh, this will never change,” and then the next week, there I am, changing it. A website is a never ending project. Code rots. It needs updating.

This also becomes a problem when coding on a team. Your team member probably has no idea that the selector you used, probably named in a schematic way for your CSS, is also a JavaScript selector. Heck, even for myself, when I come back to code I wrote a month ago, I have no idea what it does until I dig back into it.

So your easy decision to use the same selector when initially coding the website just made the maintenance that much more difficult.

To Conclude

Taking small steps, such as differentiating between CSS and JavaScript selectors, makes it easier to maintain a website as a whole. It makes it easier for teams to work together easily, without having to dig deep into code to find out how something works. Even if you are the only person on the project, maybe it’s a personal project, you can’t tell me you’ll remember exactly what that class name does a month from now, can you?

Make it easier on yourself, and others.

Of course, this is all up for debate and people are going to code the way they feel comfortable coding. But, it’s something to think about!