8 things to avoid doing in CSS - Programming with Mosh (2024)

Some people say that CSS is easy to learn and hard to master, and they couldn’t be more right. In fact, learning the basics of CSS is really straightforward. However, it’s also pretty easy to make some common mistakes. In this article, you will learn how to recognize and avoid them.

1 – Too much specificity

Check out the following CSS rule:

#external-wrapper > .items-list + .actions a.link,#content header nav.links > ul a,section#external-wrapper footer.page-footer > ul a { /*...*/}

There are some big problems with the above selectors:

1. They’re using IDs, which significantly increases the specificity of your rule
2. They are long, and long selectors also increase specificity.
3. They unnecessarily prepend class names with an element (e.g. footer.page-footer). This not only increases specificity, but it also limits reuse.

What to do instead

As a general rule, your selectors should be as short as possible. One level is perfect. Two levels is OK. Three levels should be your maximum. Lastly, avoid using IDs in your selectors (we will talk a bit more about this below) and don’t prepend tag names to your classes.

2 – Misusing !important

Again, the specificity problem. Using !important normally means you’re trying to override some property with a higher specificity or you don’t want other developers to be able to override a property that you’re setting. In the first case, you might be trying to customize a third-party component, for example. That would be a fair use case, since you have no control over external code (unless you decide to maintain your own fork of it…). In case you don’t want other people to override one or more properties from a rule you’re defining, the question you need to ask yourself is: why? Why shouldn’t other devs be able to customize some aspect of an app style, especially if you’re all working on the same project? If there isn’t a really good answer to this question, then maybe you should reconsider your use of !important.

What to do instead

If you/your team own the code containing the rule(s) you’re trying to override, consider refactoring it in order to use less specific selectors (see previous item). This way, you’ll be able to ditch !important by simply using another selector with the same specificity.

3 – CSS’s @import

@import url("font-face.css");@import url("base.css");@import url("utilities.css");

When you import stylesheets by using the CSS @import at-rule, this is what happens:

1. Your HTML file is loaded
2. Your CSS file is loaded
3. The @import at-rule is found and the referred file is loaded
4. If the imported stylesheets contain more @import’s, these additional stylesheets will be loaded too.
5. Only after all stylesheets are loaded, the page will continue to be rendered.

What to do instead

Always favor the <link> HTML tag over the @import at-rule. CSS imports block parallel downloads. The best thing to do is to reduce the number of stylesheets you use (a single file is the best scenario). Using a preprocessor/postprocessor makes this task a lot simpler, since you can have multiple stylesheets and easily combine them into one single file. Minify this bundle and import it by using the <link> tag.

4 – Inconsistent naming

Sometimes, in a single project, you find rules like these:

.user-panel {/*...*/}.AlertBox {/*...*/}.items_list {/*...*/}

This is especially common on projects maintained by multiple developers, but it happens on solo works as well.

What to do instead

Your project should use a single naming convention. Choose one that works well for you and your team and stick to it. A good option is BEM, a battle-tested naming convention that thousands of teams have been using for years.

5 – Inline CSS

<div style="color: #D3D3D3; right: 0; padding: 0"></div>

Reuse is a good thing in programming. And CSS is no exception (even not being a programming language). CSS classes are meant for reuse. When you add style to some element by using the style attribute, you’re making three big mistakes:

1. Mixing markup and presentation code
2. Preventing any possibility of code reuse, since these CSS properties are specific to that element
3. Inline styles have a specificity that is higher than any external styling. Only by using !important, you could override them.

What to do instead

Simple: always use classes. =)

6 – Senseless z-index values

.sign-up-form { z-index: 99999;}

Many developers make use of insanely high z-index values when trying to put an element in front of other. When you do this, in case someone needs to move another element up in the Z axis, this person will have to set an even higher z-index value, making things worse.

What to do instead

Instead of using brute force, the way to go is to make wise and moderate use of z-index, increasing only the necessary amount to achieve the desired result. If you use a preprocessor like Sass or Stylus, there are smarter ways of handling z-index layers on your application.

7 – Using ID selectors instead of classes

I’ll repeat myself: reuse is a good thing. And IDs cannot be reused. I mean, an ID can be used by only one element on a single page. Besides, IDs increase the specificity of a selector in a way that it can only be overridden in these cases:

1. By another selector using the same ID
2. Using !important
3. Using inline styling

What to do instead

IDs shouldn’t be used for styling. The only exception that comes to mind is styling some page/component whose markup you don’t control. In this case, if all you have to refer a certain element is its ID, then you’re good to go. For all other situations, favor CSS classes.

8 – Very generic class names

Defining classes with too generic names can be a problem as well. With names like .card, .panel, .box or .grid, for example, chances are that a conflict will happen at any moment, especially if you import third-party stylesheets on your app.

What to do instead

If you want to keep your class names short, maybe adding a prefix (like .be-card or .zo-grid) is the way to go. Name mangling is another excellent option. By using CSS modules, for example, your stylesheets will be scoped and your class names will be automatically mangled.

Conclusion

• Don’t use too specific selectors. Avoid prefixing classes with tag names.
• The use of !important should be as moderate as possible. A good use case is to override third-party styling.
• Don’t use CSS import. Always favor the <link> tag.
• Choose a naming convention and stick to it.
• Don’t use inline styling. Always put your style code in separate stylesheets.
• Use z-index wisely. Don’t brute-force z-index values.
• Don’t use IDs in CSS unless you’re trying to style third-party code, whose markup you don’t control.
• Avoid too generic class names, since they’re conflict-prone.

Do you want to become a master programmer? If so, you need to check out Mosh’s courses. They’re the best online programming courses out there! And if you liked this article, share it with others as well!

Related

Tags: bad practices, code smells, css