If you are a little anglophone you must know the excellent Podcast shoptalkshow The principle of the podcast is simple: you can ask your question in audio and web pros respond.

Recently Chris Coyier answered the following questions:

How can you tell if your CSS is bad?

What are the signs that the code is optional, or that the developer has not done a good job?

What do you look in the code to determine whether it is good or bad?

As I am a super bilingual I decided to offer you a translation for those who have a little trouble with the American accent. I will share some small techniques (there are probably things I forgot) to allow you to judge your CSS, this will give you an idea of ​​its quality, maintainability and integrity …

Cancel styles

Any CSS rule that removes style (except in a reset) must trigger an alarm bell. The definition of CSS is: cascading styles. Properties must inherit from things defined previously. Declaring more rules to remove style does not make sense.

All CSS declarations like these:

    border-bottom: none;
    padding: 0;
    float: none;
    margin-left: 0;

… Are usually bad news.

If you want to remove the borders, you probably applied their style too early. It is really difficult to explain, I will expose with a simple example:

    h2 {
        font-size: 2em;
        margin-bottom: 0.5em;
        padding-bottom: 0.5em;
        border-bottom: 1px solid #ccc;

Here we offer all of us h2a font size and a margin, but also a bit of padding and a border to separate them from the next item. But, perhaps, we have a situation where we do not want nets on the edge, maybe we have a situation where we just want one h2.

So we will have to write more rules to create less style:

    h2 {
        font-size: 2em;
        margin-bottom: 0.5em;
        padding-bottom: 0.5em;
        border-bottom: 1px solid #ccc;
    .no-border {
        padding-bottom: 0;
        border-bottom: none;

Here we have about ten lines of CSS and a filthy class name. It is much better to have semantic class names :

    h2 {
        font-size: 2em;
        margin-bottom: 0.5em;
    .headline {
        padding-bottom: 0.5em;
        border-bottom: 1px solid #ccc;

In this case, we have 8 lines of CSS, without anything undoing, and a nice class name. The more you sink into a CSS sheet the more you need to add styles, never pull them out. If at some point you have to remove style, you have surely added properties too quickly. This is a very simple example, but it illustrates my point perfectly.

Imagine a CSS like this with tens of thousands of lines … The file size explodes unnecessarily by adding unnecessary properties. Never start with an overly complex style. You may have to cancel your work later, you will end up writing more CSS to display less style. As soon as I see a CSS that cancels the previous style, I can be pretty sure that it’s because an element is poorly architectural and the order in which things were built / written need a retouching.

The magic figures

This notion can be compared to a scarecrow. I hate magic numbers. A magic number is a value that is used “because it works”.

Consider the following example:

    .site-nav > li:hover .dropdown{

top: 37px; Is a magic number.

The only reason this works, probably, is because lithe inside of it .site-navshould be 37px high, and the drop down menu should appear at the bottom of it … The problem? 37px is entirely circumstantial and as such, we must not place any confidence in this number. What if someone changes the font size .site-navto 29px height? This number is no longer valid and the next developer needs to know to update it. What happens when Chrome displays 37px, but IE displays 36px? This number only works in a given situation. Never, never use numbers just because they work. In this situation, it is better to replace top: 37px;bytop: 100%; Which in fact means “all the way from the top”.

Magic numbers have several problems associated with them. As above, they can not be reused, but also, with their “just because it works”, it is difficult to communicate to another dev from where that number has come. If you had a more complex example that uses a number and the magic that figure has become invalid, you are facing one or more of the following problems:

  • The next dev does not know where the magic number came from. It deletes it, so you win a return to square one.
  • The next dev is cautious, because he does not know where the magic number came from. He decides to try to solve the problem without touching this magic figure. This means that an old, useless, old-fashioned, magic number stays in the code, and the next dev has simply made a specific hack over it. You got pirated your style.

Magic numbers are bad news; From experience they are updated sooner or later, they confuse the other developers, they can not be explained, they can not be trusted. There is nothing worse than targeting someone else’s code and seeing an inexplicable number. If so, you wonder why it is necessary and whether or not you will dare touch it. As soon as I see magic numbers in CSS I start asking questions. Why is this here? What should be done ? Why does it work with this number? How to achieve the same result without this magic number? Avoid magic numbers like the plague.

Required selectors

The notion of selector required is coded as follows:

    ul.nav {}
    a.button {}
    div.header {}

Basically, it is the selectors that are unnecessarily prefixed by an element. This is bad news because:

  • They totally inhibit reuse on another element.
  • They increase the specificity.
  • They increase the rendering time, which reduces performance.

These selectors can, and should be:

    .nav {}
    .button {}
    .header {}

Now I know I can associate .navwith one ol, I can apply .buttonfor one input, and, when the site will be ported to HTML5 I can quickly exchange my divfor an item headerwithout worrying about invalidating any styles.

As far as performance is concerned, it is only a very small question, but it is still a problem. By specifying selectors you increase the workload of a browser.

More extreme examples could be:

    ul.nav li.active a {}
    div.header a.logo img {}
    .content ul.features a.button {}

All these selectors can be shortened massively, or totally rewritten:

    .nav .active a{}
    .logo > img {}

This will help us to:

  • Lighten the code
  • Increase performance
  • Enabling greater portability
  • Reduce specificity

As soon as I see the required selectors when I scroll through a style sheet I immediately want to know why they are written so verbose and how we can delete them to be as short as possible.

Raw / Absolute Values

Like magic numbers, hard-coded values ​​are also bad news. A hard-coded value could be something like this:

    h1 {
        font-size: 24px;
        line-height: 32px;

Here line-height: 32px;is not cool, line-height: 1.333is a much better choice .

Line heights should always be adjusted relatively to make them more tolerant and flexible. If you ever change the font size of one h1, you want to know that your line-heightwill follow the move. Do not have a relative relative to it line-heightmeans that if you want to change the size of your title you will end up with properties like:

    h1 {
        font-size: 24px;
        line-height: 32px;
    /** Title principal h1 **/
    .site-title {
        font-size: 36px;
        line-height: 48px;

Here we must continue to add a fixed line height indefinitely as our base size is not flexible enough. To make our code production more fluid, you have to change the line-height:

    h1 {
        font-size: 24px;
        line-height: 1.333;
    /** Title principal h1 **/
    .site-title {
        font-size: 36px;

This does not seem to be a huge difference, but on every text element of a large project, this impact is important.

ATTENTION: These rules do not apply only to the line-height. Virtually any raw hard-coded value in a stylesheet should be treated with caution and mistrust.

These absolute figures will never be time-tested, flexible or indulgent, and should therefore be avoided. The only things that must have their hard-coded values ​​are the sprites since they are associated with images where the size is fixed. As soon as I see a hard-coded unit in a style sheet I want to know why it is needed and how it could be avoided.

The Woodcutter

The woodcutter’s method is comparable to magic numbers. In the CSS world, you use hard-coded magic numbers and a variety of other techniques to force a rendering mode. Consider, for example:

    .foo {
        position: relative;
        z-index: 99999;
        height: 59px;
        float: left;

These statements are simply horrible. They are heavy, force layout, affect statements that are clearly used only to hack the layout only in a specific case. This type of CSS is representative of a mis-coded layout that requires this kind of manipulation, a lack of understanding of the box model, layout, or both.

A properly coded layout should never use the woodcut method. With a good understanding of the box model and a suitable grid system you should never again find yourself in this situation. As soon as I encounter CSS coded this way I ask myself how this has happened, and how it is possible to remove these rules to start on better bases.

Dangerous selectors

A “dangerous selector” is a selector with too much range. Here is a very simple and obvious example of dangerous selector:

    div {
       background-color: #FFC;
       padding: 1em;

This statement will scream any developer: why the heck would you choose every div of your site? Good question … So why are there selectors like aside{}? Or header{}or ul{}? The problem with these selectors is that they are high level and they will eventually lead to defeat CSS, explained in the previous section.

Take the example of header{}

Many people use an element headerto identify their main header – which is a good idea – however, if you style it headerlike this:

    header {
        padding: 1em;
        background-color: #BADA55;
        color: #fff;
        margin-bottom: 20px;

… in this case it is not correct. headerDoes not mean the entire header of your site and by reading the documentation it is well specified that headercan be used for any header. A good example is to target the element with a class .site-header{}.

Giving a specific style to a generic selector is dangerous. By following the cascade logic, the changes will be reflected in areas where they should not start as soon as you start using this element. You will need to cancel these statements (by adding more code to give less style) in order to combat this. Be sure to select your selectors correctly.

Let’s take as an example :

    ul {
    header .media {

As soon as I see a selector of alone, or at the head of a very basic abstraction class, as above, I start to panic.

I know that the scope of these selectors is too broad and will quickly create trouble. As soon as we try to re-use these elements we will inherit the style that we do not necessarily want because somewhere there is a more important selection rule that will take over.


!importantit is very good. It is a very useful tool. However, !importantshould only be used in certain circumstances. !importantShould always be used as prevention and not as a hack. I mean there are times when you know that a certain style must prevail. For example, you know you’ll always want your errors to be red, so this rule is quite correct:

        color: #c00!important;

If the error occurs in a divwhere the text is still blue, we can be sure that we want to break this rule in the case of errors. We always want red errors because this is an error, and the user interface must always remain consistent. Here we can anticipate !importantbecause we know we always want red errors.

importantIs bad when used as a hack. It is used to come out of a specificity problem, and recourse to !importantis used to break a stalemate by forcing things to work.

Using !importantthis way circumvents problems caused by poor CSS architecture. It does not solve all the problems, but corrects the symptoms. The problems still exist, but now with a layer of super-specificity that will take over the specificity already added.

Use !importantto get out of a perilous situation is not advised. Rethink your CSS architecture and try to combat these problems by refactoring your selectors.


They idare of no use and should never be used in CSS because of their increased specificity. Using them idin your HTML for your JS anchors can be a good idea but never in CSS.

The reasons are simple:

  • There is only one ID per page.
  • Classes can exist only one, or a million times per page.
  • The idare specific and it is much more difficult to reuse them for another part of your site.
  • One idis 255 times more specific than a class …
  • This means that you will need a chain of 256 classes to replace one id.

If this last point did not convince you then I do not know what you need … As soon as I see an ID in a style sheet, I replace it with a class. The evolution of projects, as well as the specificity is a spiral that you must avoid at all costs. Maintaining a low level of selection is essential.

Corn Exercise: Try to solve this problem elegantly.

Bulk Class Names

A “bulk” class name is not specific enough for its intended use. Imagine a class .card. What does this do? This class name is not specific enough. Its naming is very bad for two main reasons:

  • You can not know its purpose with the class name alone.
  • It’s so vague that it could very easily be redefined accidentally by another dev.

The first point is the simplest. What does it mean .card? What are its properties? Style or layout? Is it a concept where a card is a component? Is this a class you add to a card to play on a poker site? Is this the image of a credit card? It’s hard to know, because it’s far too vague. In the example of a credit card, this naming is better: .credit-card--image{}. Much better yes, definitely!

The second problem with bulk class names is that they can very easily be (accidentally) reassigned / redefined. Let’s say you are working on an e-commerce website using again .card, that is the user’s credit card linked to his account. Now imagine another dev arrives and wants to add features to send an order to someone as a gift, with the ability to add a card with a message about it. It may be used .cardagain somewhere, so your class will be crushed and hard to identify.

All this can be avoided by using much stricter class names. A class such as naming .userand .cardthis is bullsh $ t: they are difficult to understand quickly and easily crushed by accident. As soon as I encounter class names in bulk I wonder how can they be renamed. Class names should be as precise as possible.

In conclusion

If your CSS has many of the examples above, chances are that it will be sick. These examples are things I meet on a daily basis and I try to avoid them at all costs. When working on larger projects that have been going on for months and months (which ultimately turns into years), it is essential to stay on course, maintaining a global vision of the project. (The more you split your components into smaller modules, the easier it will be for maintenance.)

Of course, there are exceptions to any rule, but they must be assessed on a case-by-case basis. For the most part, I work hard to avoid them.

Now it is time to preach in your turn the good word by following these precious counsels.

I invite you to read The different types of MySQL columns


Am a tech geek.. Do you wanna know more about me..? My contents will do tell you.

Pin It