• CSS Naming Conventions that Will Save You Hours of Debugging
  • By Ohans Emmanuel
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: unicar
  • Proofread by: Dazhi1011, Swants

These CSS naming conventions will save you a lot of debugging time

I’ve heard a lot of developers hate CSS. In my experience, this is often because they haven’t taken the time to learn CSS.

CSS may not be the most beautiful “language,” but it has been an important tool for beautifying the Web for more than two decades now. That’s not bad, is it?

Still, the more CSS you write, the easier it is to spot a huge flaw.

Because CSS is really hard to maintain.

Poorly written CSS in particular can quickly become a programmer’s nightmare.

Here are some naming conventions that you can follow to save time and effort and avoid detours.

You must know that, don’t you?

A hyphenated string

If you write a lot of JavaScript, you know that it is common practice to use Camel case for variables.

var redBox = document.getElementById('... ')
Copy the code

That’s good, right?

The problem is that this nomenclature doesn’t work with CSS.

Please do not use the following name:

.redBox {
  border: 1px solid red;
}
Copy the code

Instead, you can write:

.red-box {
   border: 1px solid red;
}
Copy the code

This is a very standard CSS naming convention. In other words, easier to read.

This is also consistent with the CSS property names.

// Correct
.some-class {
   font-weight: 10em
}
// Wrong
.some-class {
   fontWeight: 10em
}
Copy the code

BEM naming convention

Different teams have different methods for writing CSS selectors. Some teams use the Hyphen Delimiters method, while others prefer a more methodical nomenclature called BEM.

In general, these CSS naming conventions attempt to solve three types of problems:

  1. What does a CSS selector do just by name
  2. Is it generally clear from the name where a selector can be used
  3. You can see the connection between the CSS classes in their names

Have you ever seen a class name like this:

.nav--secondary {
  ...
}
.nav__header {
  ...
}
Copy the code

This is the BEM naming convention.

Explain the BEM code to a 5-year-old

The BEM specification attempts to break down the entire user interface into small, reusable components.

Let’s take a look at the picture below:

This is an award worthy matchstick man πŸ™‚

Alas, it is not πŸ™

The matchstick man represents a component, such as a design block.

As you might have guessed, the B in BEM stands for ‘Block’.

In practice, “block” can mean a site navigation, header, footer, or some other design block.

As explained above, the ideal class name for this component is Stickman.

The component should look like this:

.stick-man {
  
 }
Copy the code

We’re using a hyphen here, good!

E stands for Elements

The E in BEM stands for element.

The overall block design is often not isolated.

For example, the matchstick man has a head, two beautiful arms and feet.

The head , feet, and arms are all elements within the component. They may be seen as child components, i.e. children of the overall parent component. These heads, feet, and arms are elements in the component. They can be thought of as child components, or parts of a parent component. Using the BEM naming convention, the class names of these elements can be generated by adding the element name after the two underscores.

Such as:

.stick-man__head {
}
.stick-man__arms {
}
.stick-man__feet {
}
Copy the code

M is for Modifiers

M stands for modifier in BEM nomenclature.

What if the matchstick man had a modifier like blue or red?

In a real world scenario, this could be a red or blue button. This is the qualifier in the component described earlier.

With BEM, the class name of each of these modifiers can be generated by following two hyphens with the element name.

Such as:

.stick-man--blue {
}
.stick-man--red {
}
Copy the code

The last example shows the parent plus modifier. But that doesn’t happen very often.

What if our matchstick man had a different head size?

This time the element is decorated. Remember, an element is a child of an overall encapsulation block.

Stick-man stands for Block and stick-man__head stands for the element.

As you can see from the above example, a double hyphen can also be used like this:

.stick-man__head--small {
}
.stick-man__head--big {
}
Copy the code

To reiterate, the double hyphen used in the above example is used to refer to modifiers.

So you get the idea.

That’s the basic use of BEM.

Personally, I generally use only hyphenation for class names in small projects and BEM for projects with more complex user interfaces.

Learn more about BEM here

BEM – Block Element Modifier: _BEM – Block Element Modifier is a methodology, that helps you to achieve reusable components and code sharing in the…_getbem.com

Why use naming conventions?

There are only two kinds of problems in computer science: cache invalidation and naming. – Phil Karlton

Naming is really hard. So let’s try to make it as easy as possible and save some time in maintaining the code later.

Correctly naming CSS classes makes your code easier to understand and maintain.

If you choose the BEM naming convention, it will be easier to see the relationships between design components/blocks when looking at markup.

Feeling good?

Name of the CSS associated with JavaScript

Today is John’s first day at work.

He was given the following HTML code:

<div class="siteNavigation">
</div>
Copy the code

Having just read the article, John realized that this naming method is not the best method in CSS. So he changed the code to look like this:

<div class="site-navigation">
</div>
Copy the code

Doesn’t it look good?

But what John didn’t expect was that he messed up the entire codebase 😩😩😩

Why is that?

In JavaScript code, there is navigation, which is related to the previous class name siteNavigation:

// Javascript code const nav = document.querySelector('.siteNavigation')
Copy the code

Due to the class name change, the nav variable is now null.

Good sorrow mulberry. πŸ˜” πŸ˜”

To prevent this from happening, developers have come up with a number of different strategies.

1. Use js- class name

One way to reduce such bugs is to name methods using the class name of JS -. Use this method to indicate the association between the DOM element and the JavaScript code.

Such as:

<div class="site-navigation js-site-navigation">
</div>
Copy the code

Also in JavaScript code:

//the Javasript code
const nav = document.querySelector('.js-site-navigation')
Copy the code

According to the naming convention, anyone who sees the class name js-site-Navigation will know that there is a section of JavaScript code associated with the DOM element.

2. Use Rel properties

I haven’t used this method myself, but I’ve seen others use it.

Are you familiar with such code?

<link rel="stylesheet" type="text/css" href="main.css">
Copy the code

In general, the REL attribute defines the relationship between a linked resource and the file that references it.

Looking back at John’s example, this approach suggests that we write it as follows:

<div class="site-navigation" rel="js-site-navigation">
</div>
Copy the code

Also in JavaScript:

const nav = document.querySelector("[rel='js-site-navigation']")
Copy the code

I have my reservations about this approach. But you’ll probably see them in some code base. This approach is like saying, “OKAY, there’s an association here with Javascript, so I’ll use rel properties to represent that association.”

The Internet is a place where there are often an infinite number of “solutions” to the same problem.

3. Don’t use data Attributes

Some developers use data attributes as JavaScript hooks. That’s not right. By definition, data attributes are used to store custom data.

Data attributes are used brilliantly here. As this tweet puts it.

Bonus tip: Write more CSS comments

This has nothing to do with naming conventions, but it will save you time.

Although many Web developers try not to write Javascript comments or only for certain situations, I think you should write more CSS comments.

This is because CSS is not the most elegant “language”, and structured comments can take you less time to understand your code.

No harm, no good.

You can see how well Bootstrap comments are written. source code

You don’t need to write a color: red comment to tell yourself that you’re setting the color red. But if you’re using a CSS trick that isn’t straightforward, it’s a good time to write a comment about it.

Are you ready to become a CSS champion?

I’ve created a guide that will make your CSS skills soar. Get your free ebook here

Seven CSS secrets you didn’t know.


The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.