In this article, we will discuss 8 common CSS mistakes that web developers make, and how to avoid them.
CSS is a powerful language for styling web pages, but it can also be tricky to use correctly. Even experienced web developers can make mistakes with CSS.
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:
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.
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.
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.
@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:
Always favor the 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 tag.
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.
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.
<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:
Simple: always use classes. =)
.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.
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.
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:
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.
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.
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.
#css #web-development #html