Naming Things In CSS Is Really Hard

I love front-end development, but there is one thing about it that I do not particularly like: naming things. Using ID’s and classes on HTML elements and deciding what to name things in CSS is extremely hard. Even harder than solving cross-browser bugs.

Proving how difficult naming in CSS is, there are numerous methodologies such as; SMACSS (Scalable and Modular Architecture for CSS), BEM (Block Element Modifier), OOCSS (Object Oriented CSS), ACSS (Atomic CSS Architecture) and a few others.

Even though we have all of these methodologies at our disposal, they each have their own caveats and learning curve. They all also have the downside of locking you into their way of thinking and working. Once you commit to BEM, that’s it. You can’t choose to use another methodology.

Is there a better way?

To be quite honest, there isn’t. The nature of not only CSS, but programming in general is deciding what to name something is always going to be one of the hardest things you will face.

As Phil Karlton was famously quoted as saying:

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

This couldn’t ring anymore true. Do you give your header element an ID of header, do you give it a class of header or do you use a <header> element and style that in your CSS? We have so much choice and everyone seems to have an opinion on the best approach.

Which methodology?

I personally use a variation of the BEM methodology. But having said that, it can be annoying to use something like BEM because it requires you to do a lot of thinking when it comes to naming. Should a child element becomes its own block or should I make it a child element of a block?

Sometimes you end up with long CSS selectors when using BEM like: parent-element__child-element--modifier

This kind of selector is very verbose. It tells us what each element is called, we know we have a parent element, child element and a modifier class. But try and select that line using a double click in your IDE. You’ll notice your IDE will only partially select this line, unless you use the keyboard (which many don’t) then you’ll have to select it some other way.

Methodologies introduce complexity

So you have picked a methodology and now comes the hard part. Training yourself to stick to the rules of said methodology and not only that, if you are working on a team, ensuring everyone else is onboard and understands the constraints of said methodology.

In my experience, this is where things fall apart. While methodologies like BEM give us structure and some rules to abide by, it can take some time before everyone has conditioned themselves. CSS has been this wild west thing for so long, people are accustomed to doing whatever they feel is right to get the job done.

I am sure we have all been there before, not just with introducing structure to CSS but rather introducing new syntax rules and naming conventions. Everything is great at the start and then developers start getting lazy.

Once they start slacking off, syntax and formatting issues start arising. Pretty soon you’re using BEM and some bastardised form of it, further muddying the code-base and causing you nightmares.

Sure, in a language like Javascript or Python we can configure our IDE’s to abide by our rules. We can run linters and all of these magical tools that prevent deviations from syntax rules, but for CSS we have nothing.

To my knowledge, no syntax checker for BEM or any other CSS methodology exists. Probably because it would be impossible given the nature of how CSS works.

This is half of the problem. The other half is deciding when to apply BEM (or your chosen methodology). The problem is when someone decides to use a methodology, many do not know when to stop. Do you use it for everything, what constitutes an element having its own styling?

I have seen BEM specifically go well for some and go wrong for others. I worked on a freelance project 2 years back that used BEM. It started off well, but there was a tonne of confusion amongst the team.

Some developers got it, but most didn’t and ended up either using BEM for everything or not using it in places where they could have. Sadly most projects don’t allocate time for things like this. It is how it is.

In the end to get the project over the line, all care was thrown out the window. We left the BEM we had in, but the team was instructed to ship and get it done regardless of how they write their CSS.

I feel sorry for any developer who has had to change something since. I can only imagine coming into a code-base of conflicting styles would drive even the most sane developer mad.

Conclusion

I have no ideas or suggestions of my own to contribute to the naming problem. Introducing structure, peace, love and happiness into CSS is always going to be one of those dreams developers and managers are forever chasing.