CSS: The Good and the Bad

CSS: The Good and the Bad

Writing clean CSS has to be the most difficult thing. This story probably sounds familiar: you start a new project and tell yourself that’s it, this time I’m going to write clean CSS. It lasts a few days and then the code quickly spirals down into a mess.

A lot has to do with the language itself, it sucks and you don’t have a choice. While in the back-end you have several languages to choose from, for the front-end you end up with CSS one way or another. Using supersets of CSS that “compile” into it – such as LESS – alleviates many problems but doesn’t take care of the bad parts: the features that are more trouble than they are worth.

The bad parts are nesting, #id selectors and tying classes to specific HTML elements. Avoiding those dramatically improves code reusability.

Abusing nesting

Nesting is very common. It is often misused to style elements based on where they are instead of what they are.

Let’s use this blog’s CSS as an example: .widget-area .widget li { padding-bottom: 10px; } gives padding to all the list elements in the sidebar. There are a few problems with that:

  • It will backfire. If I add another listing in the sidebar it will have unusual padding, which may or may not be what I want.
  • It’s not immediately reusable. If I need a new padded list somewhere else I can either wrap it into a .widget-area div (which brings in additional styling) or find the related CSS code and add a new selector. Neither solution is ideal.
  • It’s contagious. Let’s say I am adding a new list inside the sidebar, but this one should have no padding. Because of the CSS specificity rules the only way to do it is to write an even more specific selector to override the older one, which makes the situation worse.

You can avoid those problems by styling elements based on what they are and not where they are, for example having .padded-list li { } and applying the class to the parent ul. It is still nesting but in this case it’s acceptable: you are using it to style a padded list, not to style all the lists that happen to be in the sidebar.

#ID selectors

The HTML specification states there cannot be more than one element with the same ID. This by itself kills any reusability of the code: you cannot reuse the styling for any other element.

And sure, there is only one element now, but what if months from now someone adds a second one? You can’t predict the future! Class selectors have no disadvantage whatsoever over id selectors and allow for code reuse, so you should always use the former over the latter.

Tying classes to elements

The Hungarian notation in disguise: h4.sidebar-title. What if you decide the tile should actually be an h3? You have to go find the CSS code and change it, which is frustrating.

This feature is also completely unnecessary as long as the class names are not excessively generic.


Limiting yourself to element and class selectors while avoiding nesting as much as possible gives you a great framework:

  • The element selectors give the default look for each HTML tag.
  • The class selectors allow you to override the style based on what the element is, which makes code reuse much easier as the project grows larger.

This is the trick to having clean CSS.

Leave a Reply

Your email address will not be published.