Ways to Write Better CSS

Method One: Pay Attention to Selector Specificity and Performance

Overly deep selectors can lead to high CSS specificity, making maintenance cumbersome and requiring overriding certain styles. Consequently, due to high specificity, you may using !important to override original styles.

If a single class selector can select the desired element, why complicate things with multiple layers that increase readability difficulty and specificity? In some cases, excessive selection can also impact performance, as browsers take more time to parse such selectors.

/* ❌ Nope */
.navbar .nav-item .nav-link {
}

/* ✅ Yes */
.nav-link {
}

Clear selectors provide a sense of assurance and reduce naming conflicts. However, in practical development, reading a long and specific selector is generally not faster than coming up with a good class name. If you have concerns about naming conflicts, consider referring to the BEM naming convention. Here are some principles to keep in mind:

1. Reduce selector specificity as much as possible.
2. Use !important🔗 for debugging only.
3. Avoid # selectors🔗 because IDs with the same name are invalid syntax, meaning an ID selector can only be used once, and its specificity is very high, complicating maintenance.

Method Two: Avoid Overly Fancy Selection Techniques

For the same reasons as method one, aim to use simple, low-specificity selectors to achieve your goal. This does not mean that fancy selectors are unnecessary to learn, but in most cases, a straightforward class selector can meet the requirement and is the best choice for maintenance. While experimenting with fancy selectors, remember that problem-solving should emphasize simplicity: KISS principle🔗.

Method Three: Unified Writing Style

/* Utility */
.flex {
  display: flex;
}

More and more people are embracing the practice of writing Utility-style CSS. However, if Utility styles are mixed and used without planning, it can significantly complicate maintenance. Beginners can easily write Utilities, as they just like inline styles and don’t require consideration of naming; you just apply them directly. However, this habit can become difficult to maintain as the project scale increases.

Especially for beginners, I still advocate for the importance of good naming conventions. If you are genuinely interested in Utilities, you can check out my other article: Use Tailwind Without Learning It.

/* ❌ Mixed Use */
.p-1 {
  padding: 1rem;
}

.panel {
  border: 1px solid black;
  background-color: white;
}

/* ✅ Semantic */
.panel {
  padding: 1rem;
  border: 1px solid black;
  background-color: white;
}

/* ✅ Generic Classes */
.p-1 {
  padding: 1rem;
}

.border {
  border: 1px solid black;
}

.bg-white {
  background-color: white;
}

Method Four: Stop Using Magic Numbers

Magic numbers are unique value with unexplained meaning. Early on, when CSS did not support variable syntax, we would use Sass🔗 to use variables. However, nowadays, CSS Variables🔗 are widely supported across major browsers. Extracting frequently-used style variables and referencing them when needed can make CSS maintenance easier. As the project scale increases, it’s even more important to avoid scattered variables in your code.

Refer to the timeline example below, which uses both native CSS and Sass variable syntax to manage various variables, making CSS easier to maintain:

Method Five: Abandon Old-School Web Layout Methods

If there’s no need to maintain an old website, then stop using outdated methods to design websites! Old techniques such as table🔗, float🔗, and manually computing % values should be replaced with embracing Flexbox🔗 and Grid🔗 to make your websites more flexible and easier to maintain.