webdeasy.de

Posted on Sep 1, 2019 • Edited on Jun 3 • Originally published at webdeasy.de

You should avoid these 7 CSS No-Gos! ☝️

#css #webdev #beginners

Updated version is available (click)! 🔥

Again and again one reads CSS tips and what one must consider in order to create fancy websites as fast as possible. Sometimes it helps to see the bad examples to know what is really good. And exactly these CSS No-Gos you can find here!

Important: The following No-Gos are only my personal opinion for "bad" CSS. These are not fixed rules, but only tips from my own experience!

1. Style-Resets

Each HTML element has some default styles, which should make the element unique. This also determines the application area or purpose of the element. Therefore you should use these default styles and not reset them. Using the example of the p tag the problem can be explained well.

/* No-Go */

/* Default Style */
p {
  display: block;
  margin-top: 1em;
  margin-bottom: 1em;
  margin-left: 0;
  margin-right: 0;
}

/* Wrong: Our custom Style */
p {
  display: inline-block;
  margin: 0;
}

We would overwrite the default display and margin attribute. Here a span element is more suitable, because it has no styles by default.

It would be better this way:

/* Correct: Our custom Style */
span {
  display: inline-block;
  margin: 0;
}

Of course we have to adapt and sometimes overwrite styles for many elements, because otherwise they would not match the CD (Corporate Design) and each page would look identical. But you can pay a little attention to it. This saves CSS code and therefore important seconds when loading the page.

Here you can find a list with the default styles for all HTML tags.

2. Unsuitable class names

This No-Go is very important if you want other developers to customize the code. Similar to well chosen comments, class names are an important step for readable code.

On this point, we must distinguish between three errors.

2.1 Too short - meaningless

If class names are too short, they are usually meaningless. What can we do with f? Right: nothing! Therefore always choose a meaningful class name and try to use as many helper classes as possible. You should not do it that way:

/* No-Go */

.f {
  color: red;
}
.a {
  margin: 1rem 3rem 2rem 3rem;
}
.cf {
  display: none;
}

This is what meaningful helper classes would look like:

.red-color {
  color: red;
}
.margin-small-big {
  margin: 1rem 3rem 2rem 3rem;
}
.display-none {
  display: none;
}

2.2 Identical to HTML tag

These class names are understandable but completely superfluous. We can already select HTML elements by the element name section or span and don't need an additional class with the same name. The following is a No-Go:

/* No-Go */

section.section {
  min-height: 80vh;
}
span.span {
  color: red;
  font-size: 12px;
}

That would be better:

section {
  min-height: 80vh;
}
span {
  color: red;
  font-size: 12px;
}

2.3 Confusing

Confusing class names are the worst. If I read no-margin in the code, I also assume that the margin is set to zero in CSS. Also with color-red everyone assumes that the background color or font color is set to red. It should not look like this:

/* No-Go */

p.color-red {
  color: green;
}
.no-margin {
  margin: 3rem 0.5rem;
}

Class names that don't confuse could look like this:

p.color-green {
  color: green;
}
.margin-big-small {
  margin: 3rem 0.5rem;
}

3. Important Keyword

We all know it: A style that can't be changed because it's often overwritten or comes from a plugin. Then we like to use the little magic word !important in our CSS.

It causes this style to always apply and the problem is supposedly fixed. But this is the beginning of a vicious circle. The next time you want to change it and are too lazy to search again, you use the keyword again and sometime there will be complete chaos.

Therefore you should always think and search well before using the keyword. Sometimes it is unavoidable, but more often it can be solved differently.

That's why I don't want to do this:

/* No-Go */

span.foobar {
  color: red!important;
  margin-top: 4rem!important;
  font-size: 12px!important;
  border-bottom: 1px solid #000!important;
}

4. Empty selectors

Of all CSS No-Gos this is probably the least important, but at the same time also the No-Go, which can be avoided most easily.

We're talking about empty selectors. In other words, selectors that do not contain any attributes. These selectors always lose a few bytes of memory.

If this often occurs in the code and we have a lot of large CSS files, it can affect the loading time of your page.

That's why nothing like that got lost in CSS:

/* No-Go */

p { }
span { }
.no-margin { }
footer { }
footer > a { }

5. Overwriting Styles

We've already talked about the key word "!important". This allows us to overwrite styles so that this CSS rule always applies. If we use this too often we have big problems with later changes. But even without the keyword we should avoid overwriting for the most part.

You should avoid that:

/* No-Go*/

p {
  font-size: 2em;
  color: #FFF;
}

/* ..other code.. */

p {
  font-size: 2.2em;
  line-height: 20px;
}

/* ..other code.. */

p {
  font-size: 1.8em;
}

But you can easily avoid this mistake. Instead of always adding a new style, you can simply search for an occurrence in your CSS files for CTRL + F and change it accordingly.

This saves us code, thus storage space and the file also remains clearer.

It could look like this:

p {
  font-size: 1.8em;
}

6. Too much absolute positioning

I love absolute positioning. It can be really helpful in many cases and is also unavoidable and good in some cases.

However, there are actually still people who position each element absolutely. There are many reasons why you shouldn't do that. On the one hand it is much more difficult to position each element pixel by pixel. A lot of paperwork, a lot of trial and error and it looks unclean.

It is also much more difficult to make a page responsive and you have to insert a lot of breakpoints to make the page look good at any resolution. Why make your life harder than it is…? But as I said: there are also a lot of good applications for absolute positioning.

7. Too much CSS

A problem which I see e.g. with prefabricated WordPress themes. You already have a lot of CSS code (also a lot of unnecessary code) and then you even add your own code. So the chaos is complete.

This is where many of the listed No-Gos grab. Overrides, empty selectors, frequent use of "!important" and above all: confusing! Therefore you should directly remove or rewrite all code that is not needed or that you change.

But also for other projects you should write minimal code. It makes many things easier and minimalism is now modern and beautiful.

Conclusion

So there are many points you can consider to write clear and performant CSS. You never stop learning and you can always improve your "code". I also know that you can't always avoid these CSS No-Gos, but you can always try to improve yourself.

Please check this out if you are looking for JavaScript Challenges (sorry for the little ad):

Article No Longer Available

Thanks for reading! If you liked this article, please let me know and share it! If you want to you can check out my blog and follow me on twitter! 😊

Top comments (20)

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Sep 2 '19 • Edited

Style-Resets

I disagree. By resetting the styles you create uniformity between all browsers. Yes you may have to set them again, but it gives you complete control. I use a modified version of meyerweb's reset CSS, which resets, then sets key elements. Here's a link if you're curious: github.com/nataliedeweerd/blank_we...

Mike Ekkel • Sep 2 '19

I agree with this. To add to that using the example given in this post: a paragraph may have been designed a specific way for my project, let's say with 2em of margin at the top and bottom. I would definitely want to reflect that in my code, which means overwriting the default styling.

webdeasy.de • Sep 2 '19

Yes, that's absolutely ok! :)

Paul Rumkin • Sep 2 '19 • Edited

There exist two technics: style nullifying (reset.css) and definition of default styles for all browsers (normalize.css). The second option is preferable.

webdeasy.de • Sep 2 '19

That's why I have noted that these are my ideas of "good" CSS. :)

But thank you for your comment, I think that many have such a view. I don't think that additional styles require resets anymore.

Lawrence • Sep 2 '19 • Edited

I think you need to reassess your concept of how much space and bandwidth things like empty selectors actually consume. First, unless you have 50+ unused selectors, you'd be unlikely to see more than a 10ms increase in download time. Css is also cached and compressed if configured properly, so the size is significantly less (0 aside from initial load). They are good points from a readability standpoint, but there are much smarter ways to optimizing performance than worrying about a few dozen characters in a css file.

webdeasy.de • Sep 2 '19

I know it's only a very small fraction. But it also has something to do with clean code and helps to make it easier to read or search the code.

Anyway, thanks for your comment! :)

Ross Thorne • Sep 2 '19

p.color-red is illustrative, I can see why you've used it, but generally you want to avoid naming your styles so tightly coupled to their appearance. What if you change your colour palette? Sure changing one class name should be simple, but you don't want it littered all over the place.
Using a more semantic description like p.accent should be preferable

Taufik Nurrohman • Sep 2 '19

It depends. Some functional CSS classes use the same name as the HTML tag name not to be used on that tag but to be used on other tags so that the display will looks the same. One example is the .button class. Although some controversial opinions about .button and .btn had emerged along with the HTML5 semantic trend in the past.

Other examples:

.h1 {}
.h2 {}
.h3 {}
.h4 {}
.h5 {}
.h6 {}
.code {}

I use .p class as well just to make sure that some embed code in the paragraph flow will have sufficient margin. And in my opinion, it is better than that .mt-1 and .mb-1 class name.

<p>aaa</p>
<iframe class="p"></iframe>
<p>aaa</p>

webdeasy.de • Sep 2 '19

Good point! A possibility I hadn't thought of, but it makes sense.

Patrick Keßler • Sep 2 '19

Oh god, WordPress themes... Current problem with the project I work on. Horrible.

Lawrence • Sep 2 '19

Doesn't actually have anything to do with WP. It's a matter of the poor development done by whoever created the theme. You can find this problem on any platform even custom developed ones.

Patrick Keßler • Sep 2 '19

I'm talking (bad) themes in general. Not working with WP.

webdeasy.de • Sep 2 '19

Sometimes...yes! :o

Daniel Molnar • Sep 3 '19

To style resets part:

You should always choose HTML tags by their semantic purpose, not by their appearance.

RobKohr • Sep 3 '19

Naming classes based on their style such as .color-red is wrong in most cases. Stick to more semantic ones like .error-message. Ask, why should this be red, and then name it based on that.