Mohan pd.
Mohan pd. Author of The Coders Blog. Also a professional fullstack javascript developer working with various tech company and client around world.

Understanding Cascade, Specificity in CSS.

Aug 07, 2019 · 5 minutes
Understanding Cascade, Specificity in CSS.

In css, the best way to accomplish something is often contingent on your particular constraints and how precisely you'll want to handle various edge cases. While there are some trick or useful recipes you can follow. Mastering CSS requires an understanding of the principle that makes those practices possible.

In the first part of this blog, we will discuss about cascade in CSS. Though we have heard about fundamental of CSS i.e. the cascade, the box model but mastering them we must first know fundamental and know them deeply.

The cascade

CSS is all about declaring rules. Under various conditions, we want certain thing to happen. The browser then takes these rules, figure out which one to apply where and use them to render the page. When you look at small example, this process is usually straightforward. But as your stylesheets grow, your code can become complex surprisingly quickly. There are several way to accomplish the same thing in CSS, but depending on which solution you use, result may get widely different. A key part of CSS development comes down to writing rules in such a way that they're predictable.

Each rules may be straightforward on its own, but what happens when two rules provide conflicting information about how to style an elements?
Simply, one of the rules doesn’t do what you expect because another rule conflict with it. Predicting how rules behave requires an understanding of the cascade.

The cascade is the name for this set of rules. It determines how conflict are resolved, and it's a fundamentals part of how the language works. When declarations conflict, the cascade consider three thing to resolve the difference:

  • Stylesheets Origins: Where the style come from. Your styles may apply with conjunction with the browser default styles.
  • Selector specificity: Which selector takes precedence over which.
  • Source order: Order in which styles are declared in the stylesheets.

cascade-order-in-css

So, Lets understand them one by one in detail.

Understanding Stylesheets Origins

The stylesheets you add to your web page aren’t the only ones the browser applies. There are different types, or origins, of stylesheets. Yours are called author styles; there are also user agent styles, which are the browser’s default styles. User agent styles have lower priority, so your styles override them.

Important declarations

Declarations marked !important are treated as a higher-priority origin, so the overall order of preference, in decreasing order, is this:

  • 1. Author important
  • 2. Author
  • 3. User agent

Understanding specificity

If conflicting declarations can’t be resolved based on their origin, the browser next tries to resolve them by looking at their specificity. The browser evaluates specificity in two parts:

  • styles applied inline in the HTML
  • styles applied using a selector
Inline Styles

Inline styles get highest priority. If the inline styles are marked important, then nothing can override them.

Selector Specificity:

The second part of specificity is determined by the selectors. For instance, a selector with two class names has a higher specificity than a selector with only one. Different types of selectors also have different specificities. An ID selector has a higher specificity than a class selector, for example. In fact, a single ID has a higher specificity than a selector with any number of classes. Similarly, a class selector has a higher specificity than a tag selector (also called a type selector).

The exact rules of specificity are:

  • If a selector has more IDs, it wins (that is, it’s more specific).
  • If that results in a tie, the selector with the most classes wins.
  • If that results in a tie, the selector with the most tag names wins.
Selector IDs Classes Classes Notation
html body header h1 0 0 4 0,0,4
body header.page-header h1 0 1 3 0,1,3
.page-header .title 0 2 0 0,2,0
#page-title 1 0 0 1,0,0

It now becomes a matter of comparing the numbers to determine which selector is more specific. A specificity of 1,0,0 takes precedence over a specificity of 0,2,2 and even over 0,10,0 (although I don’t recommend ever writing selectors as long as one with 10 classes), because the first number (IDs) is of the higher priority. Occasionally, people use a four-number notation with a 0 or 1 in the most significant digit to represent whether a declaration is applied via inline styles. In this case, an inline style has a specificity of 1,0,0,0. This would override styles applied via selectors, which could be indicated as having specificities of 0,1,2,0 (one ID and two classes) or something similar.

Understanding source order

The third and final step to resolving the cascade is source order. If the origin and the specificity are the same, then the declaration that appears later in the stylesheet—or appears in a stylesheet included later on the page—takes precedence. This means you can manipulate the source order to style your featured link. If you make the two conflicting selectors equal in specificity, then whichever appears last wins.

Conclusion : Two rules of thumb

As you may know, there are two common rules of thumb for working with the cascade.Because these can be helpful, here’s a reminder:

  • Don’t use IDs in your selector. Even one ID ratchets up the specificity a lot. When you need to override the selector, you often don’t have another meaningful ID you can use, so you wind up having to copy the original selector and add another class to distinguish it from the one you are trying to override.
  • Don’t use !important. This is even more difficult to override than an ID, and once you use it, you’ll need to add it every time you want to override the original declaration and then you still have to deal with the specificity.

These two rules can be good advice, but don’t cling to them forever. There are exceptions where they can be okay, but never use them in a knee-jerk reaction to win a specificity battle.