Forem: Bill Mei

The Definitive Guide to CSS Cascading and Specificity

Bill Mei — Mon, 12 Aug 2019 16:43:38 +0000

This article is an excerpt from Painless CSS.

Cascading is an important part of Cascading Stylesheets, but it’s often explained poorly and online tutorials lead to more confusion than clarity. I think that’s a shame because there is a vastly more effective mental model I’ve found for explaining CSS Cascading. Instead of thinking about “cascading” or “specificity”, the secret is to imagine it as a “CSS Tournament” instead.

Tournaments are held to determine the winner of a conflict. The purpose of the CSS Tournament is to resolve conflicts between two or more CSS properties that are trying to apply the same style onto the same HTML element.

Let’s look at an example:

p.maroon#malamute button[disabled] {
  margin: 100px;
  cursor: copy;
}
.sapphire-shepherd p.headline.content button[disabled] {
  padding: 2rem;
  cursor: wait;
}
#purple-poodle button {
  cursor: pointer;
  text-decoration: underline;
}
#teal-terrier.fullpage button.submit-btn {
  line-height: 2.5;
  cursor: help;
}

<body class="fullpage" id="teal-terrier">
  <div id="purple-poodle">
    <article class="sapphire-shepherd">
      <p class="maroon headline content" id="malamute">
        <button class="submit-btn" disabled>
          What happens when you hover over me?
        </button>
      </p>
    </article>
  </div>
</body>

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

There are four competitors in this tournament. Each competitor submits three entries into this competition:

Entry 1 consists of the number of ID selectors in the CSS rule
Entry 2 consists of the number of class, attribute, and pseudo-class selectors in the CSS rule
Entry 3 consists of the number of tag and pseudo-element selectors in the CSS rule

The number inside each box represents the count of selectors assigned to that entry.

Our competitors are fighting over the cursor CSS property, and these are the declarations in conflict:

cursor: copy;
cursor: wait;
cursor: pointer;
cursor: help;

Winning the CSS Tournament comes with a glamorous prize: the winner’s cursor value will apply to the selected button.

Let’s meet the competitors:

Competitor 1: Maroon Malamute

p.maroon#malamute button[disabled] {
  margin: 100px;
  cursor: copy;
}

This CSS rule has one ID selector (#malamute), one class selector (.maroon), one attribute selector ([disabled]), and two tag selectors (p, button).

We can summarize this competitor’s entries with a single number: 122. This number is also known as the Specificity Level (or Specificity Score) of the selector. The higher this score, the higher the specificity.

Let’s meet the other competitors:

Competitor 2: Sapphire Shepherd

.sapphire-shepherd p.headline.content button[disabled] {
  padding: 2rem;
  cursor: wait;
}

This selector has a specificity score of 041.

Competitor 3: Purple Poodle

#purple-poodle button {
  cursor: pointer;
  text-decoration: underline;
}

This selector has a specificity score of 101.

Competitor 4: Teal Terrier

#teal-terrier.fullpage button.submit-btn {
  line-height: 2.5;
  cursor: help;
}

This selector has a specificity score of 121.

Tournament Rules

While there is a conflict for cursor, the declarations below are not in competition with each other. They don’t participate in the tournament and they are all immediately applied as a style onto the button without needing to participate in the tournament.

margin: 100px;
padding: 2rem;
text-decoration: underline;
line-height: 2.5;

There are three rounds to the tournament. In Round 1, all competitors submit their score from Entry 1 into the round. The competitor with the highest score wins that round. Similarly, competitors submit Entry 2 for Round 2, and Entry 3 for Round 3.

Round 1

For Round 1, we look at the number of ID selectors for all competitors. The competitor with the greatest number of ID selectors wins this round:

Sapphire Shepherd has no ID selectors, so it is immediately eliminated from Round 1!

Once a competitor is eliminated, it doesn’t get to participate in any subsequent rounds.

Maroon Malamute, Purple Poodle, and Teal Terrier are tied at 1 ID selector each, so they all move on to Round 2.

Round 2

For Round 2, look at the number of class, attribute, and pseudo-class selectors for all remaining competitors. The competitor with the most of these wins this round:

Even though Sapphire Shepherd has the greatest number of class selectors in this round, it was already eliminated in the previous round, so it doesn’t win! It doesn’t matter if a competitor “could have won” if it stayed in the tournament—once a competitor is eliminated, it’s permanently gone.

Both Maroon Malamute and Teal Terrier are tied in first place for Round 2, so they move forward to Round 3 and Purple Poodle is eliminated:

Round 3

For Round 3, look at the number of tag and pseudo-element selectors for all remaining competitors. The competitor with the most of these wins the tournament!

Maroon Malamute has 2 tag selectors and Teal Terrier has 1 tag selector, so Maroon Malamute wins the tournament!

The final outcome is that the maroon malamute CSS rule “wins” over the others:

p.maroon#malamute button[disabled] {
  margin: 100px;
  cursor: copy
}

and the declaration cursor: copy is applied to the selected HTML element.

In this example, cursor was the only CSS property in conflict. If there were more than one property in conflict (say, two or more CSS rules both had different margin values), then we would run this tournament again for the next property (margin), starting over from the beginning.

Shortcut: Specificity Score

Now that you understand the tournament analogy, let’s simplify this whole thing to make it easier to use in practice.

First, instead of breaking up entries by ID, class, and tag selectors, let’s just assign scores to each CSS rule as follows:

Every ID selector is worth 100 points
Every class, attribute, or pseudo-class selector is worth 10 points
Every tag or pseudo-element selector is worth 1 point

Then, we’ll add up all the scores for each competitor:

Competitor 1: Maroon Malamute

p.maroon#malamute button[disabled] {}

(1 × 100) + (2 × 10) + (2 × 1) = 122

Maroon Malamute has 122 points.

Competitor 2: Sapphire Shepherd

.sapphire-shepherd p.headline.content button[disabled] {}

(0 × 100) + (4 × 10) + (1 × 1) = 41

Sapphire Shepherd has 041 points.

Competitor 3: Purple Poodle

#purple-poodle button {}

(1 × 100) + (0 × 10) + (1 × 1) = 101

Purple Poodle has 101 points.

Competitor 4: Teal Terrier

#teal-terrier.fullpage button.submit-btn {}

(1 × 100) + (2 × 10) + (1 × 1) = 121

Teal Terrier has 121 points.

Specificity Rank

Next, instead of going through the tournament round by round, let’s just sort all the specificity scores for each of our competitors from highest to lowest:

122 points: Maroon Malamute
121 points: Teal Terrier
101 points: Purple Poodle
041 points: Sapphire Shepherd

Who’s the winner? Simple! The winner of the tournament is the competitor with the highest score: Maroon Malamute. Another neat fact is that reading this list from bottom to top is the order in which the competitors were eliminated! So Sapphire Shepherd was eliminated first, then Purple Poodle was eliminated second, then Teal Terrier was eliminated third.

“Wait a sec,” you may ask, “why did you go through the trouble of explaining the whole tournament analogy when this ranking method is so much easier?” Well, that’s because this shortcut of sorting the specificity scores doesn’t work when you have more than 9 classes (or tags, or IDs, etc.) on an element. Here’s an example:

.big.big.big.big.big.big.big.big.big.big.big.big.big {
  font-size: xx-large;
}
.medium.medium {
  font-size: medium;
}
#x-small {
  font-size: x-small
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

<p class="medium big" id="x-small">
  What size am I?
</p>

Here are the “scores”:

.big.big.big.big.big.big.big.big.big.big.big.big.big {} has a score of (13 × 10) = 130
.medium.medium {} has a score of (2 × 10) = 20
#x-small {} has a score of (1 × 100) = 100

You would expect the size of the element to be xx-large, but it is in fact x-small!

In the original tournament analogy, the rounds (and entries) are separate from each other. The shortcut ranking method doesn’t work for more than 9 classes because the moment you add the 10th class to a selector which already has a score of 90, its score becomes 100 and it “overpowers” the ID selector, which shouldn’t happen. This problem occurs because we’re using a base-10 counting system, and you could avoid it by changing the base, but at that point it’s much simpler just to use the tournament analogy as your mental model.

Luckily, in practice we usually don’t write more than 9 selectors in a CSS rule, so our shortcut of adding together all the specificity scores works handily for most situations you encounter in the real world.

Exceptions to the Tournament

Normally the winner of the tournament is the CSS declaration that gets rendered; but there are certain exceptions where a declaration that is not the winner gets rendered instead:

Inline Styles

Any inline styles on an HTML element (where you write your CSS directly on the HTML element using the style attribute, instead of using a separate stylesheet) automatically override any winners of the tournament. For example:

#bold {
  font-weight: bold;
}

<p style="font-weight: normal;" id="bold">
  This text is not bold.
</p>

In addition to the reasons I described in Chapter 6 of the Painless CSS book, this is another reason why we try to avoid inline styles: they can’t be overwritten by any CSS rules we write in our stylesheets.

Counterintuitively, using inline styles can be a best practice in certain situations when you coding for a front-end framework such as React, Vue, or Angular. I have a discussion about this later in Beyond Cascading. For now, we’ll avoid using inline styles.

This is an exception to this exception! While inline styles override the tournament winners, any declarations that use the !important keyword will override an inline style.

!important

!important is a special keyword in CSS that makes your declaration always win the tournament, no matter what, even if there are inline styles on the element! It looks like this:

p {
  font-weight: bold !important;
}

#not-bold {
  font-weight: normal;
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

<p style="font-weight: normal;" id="not-bold">
  This text IS bold.
</p>

We avoid using !important in our CSS because it can’t be overwritten.^[1] If you change your mind later, you can’t overpower it with a different rule; you have to remove the !important and then also check every other rule for that element to make sure nothing else breaks, because usually the reason an !important was added in the first place was to unbreak some buggy code.

The true nightmare of a CSS author is to open up a CSS file and see !important sprinkled everywhere! Selectors in this kind of situation are called Overspecified or Overpowered.

This is also why I recommend avoiding IDs for CSS styling, because IDs are also highly powered. No matter how many CSS classes you write, you cannot override an ID.

The tournament analogy gives us an intuitive sense for why overpowered selectors are bad. If a selector is enormously powerful in the tournament, it wins faster and at earlier rounds, meaning the only way to beat a powerful selector is to write another style that is even more highly powered.

This tendency for specificity to always escalate is known as a specificity war. Like stockpiling nuclear weapons, no one wins at this war—it only becomes harder to de-escalate as specificity increases. The only way to avoid an all-out specificity war is to not stockpile highly powered selectors in the first place.^[2]

Tied until the end

What if we reach the last round of the tournament, and there is still a tie?

If we get to the end of the tournament and there is still a tie, then the final tiebreaker is the location of the CSS rule in the source CSS file. Anything that is written later (nearer to the bottom of the file) will win over anything that is written earlier (nearer to the top of the file).

If you import multiple CSS files into your HTML document, (e.g. you have multiple <style> or <link> tags), then it’s the last file (nearer to the bottom of the HTML document) that wins the tie. Thus, the tournament can never be tied all the way through, because the final tiebreaker is the physical location of the code, and this is always unique.

This is also how duplicate declarations are resolved; if you write:

span {
  color: red;
}

but then later in the same file you write

span {
  color: blue;
}

Then color: blue will get applied to your span.

Thus, the order in which you import any third-party CSS files is important, (e.g. using <link> tags, or @import) because changing the order will change the outcome of the last tiebreaker. In practice, this means the first thing we import is our normalize.css or reset.css file for standardizing the User Agent Stylesheet, followed by any third-party CSS frameworks such as Foundation or Bootstrap, followed by our own site-specific code.

The tiebreaker rule is why I recommend against tag selectors and encourage you to use class selectors instead, because tag selectors are underspecified. Tag selectors have the lowest power, so they are too sensitive to their order in your CSS file, and your design can break if you ever re-order your imports, as the tiebreaker outcome will change in a re-ordering.

Inheritance

Inherited properties are always given a specificity score of 000, no matter what their original specificity was.

#powerful {
  font-weight: bold !important;
}
.unpowerful {
  font-weight: normal;
}

<div id="powerful" style="font-weight: bold;">
  <div class="unpowerful">CSS rules everything around me</div>
</div>

Since font-weight is an inherited property on the child, it doesn’t matter that the parent is both a highly powered ID selector and has an !important, the .unpowerful selector will win in this situation.

However, if we change our HTML so that the ID #powerful becomes non-inherited,

<div>
  <div class="unpowerful" id="powerful">
    CSS rules everything around me
  </div>
</div>

then the ID will win as expected.

The “generational distance” (whether the property was inherited from a parent, or a grandparent) doesn’t matter—only CSS selectors that directly select your element have a specificity greater than 000. Only when there are no CSS rules directly selecting your HTML element will parents win over grandparents:

<div id="powerful">
  <div class="unpowerful">
    <p>CSS rules everything around me</p>
  </div>
</div>

Universal Selector

The Universal Selector * has a specificity of 000.

Non-Participants

Keep in mind that the tournament only applies to properties in conflict in each other on a selected element—if two selectors don’t select the same element, then they are not in conflict. For example, what color will the button background be?

button {
  /* Specificity: 001 */
  background-color: orange;
}

button .submit-btn {
  /* Specificity: 011 */
  background-color: green;
}

<button class="submit-btn">What color am I?</button>

The answer is it will be orange! This is because the selector button .submit‑btn is not selecting our element (it would have selected any children of a button with a class of .submit‑btn), and despite its higher power, it does not even participate in the tournament! If the second selector had instead been button.submit‑btn (notice the lack of a space), then the button background color will indeed be green.

Also keep in mind that a tournament is not needed when properties are not fighting each other. For example:

.welcome-message {
  color: salmon;
  background-color: seashell;
}

#headline {
  margin-top: 0;
  background-color: lavender;
}

<h1 id="headline" class="welcome-message">
  Welcome to my blog
</h1>

color and margin-top are talking about different things, so they can both apply to the same element at the same time because they’re not fighting each other. However, background-color is in a fight, so for this property we use the tournament to find a winner. #headline wins the tournament against .welcome-message so the element is given a background-color of lavender. The final set of properties applied to our <h1> is:

color: salmon;
margin-top: 0;
background-color: lavender;

Combinators

Combinators are ignored in our tournament. To determine the winner of a round, we follow only the scoring rules laid about above. You would think that changing from a broad selector like (the descendent combinator) to a more narrow selector like > (the child combinator) would change the outcome of the tournament, but combinators only affect whether or not the CSS rule is eligible to participate in the tournament in the first place (since it changes whether or not our element is actually selected), and they do nothing to the specificity scores.

Here’s an example; what color will our text be?

p > span {
  color: firebrick;
}
p span {
  color: aquamarine;
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

<p><span>What color am I?</span></p>

The answer is the text will be aquamarine! It totally seems like p > span should win because the extra child combinator > makes it look “more specific” since it’s narrowing down to direct children instead of all descendants, but the > does not affect any of the specificity scores, so when we run the tournament we have a score of 002 competing against a score of 002. Since the result of this tournament is a tie, the last selector p span wins because of the tiebreaker rule, and our text is given a color of aquamarine.

This example reveals the problem with the classical way of thinking about cascading. The popular explanation of comparing the CSSOM to how the HTML DOM is constructed will mislead you in this example because the structure of the tree has nothing to do with the results of our tournament.

The Painless CSS Tournament

Here is a summary of what we learned, which I shall refer to later as the Painless CSS Tournament: the bottom-up model where we take the perspective of the HTML element, instead of the perspective of the browser rendering engine:

Look at each element one by one, ask “what CSS rules apply to you?”
Look at all the rules you found in Step 1, and list all the properties that apply from those rules (e.g. include all inherited properties and discard any non-inherited properties from parents).
From the list of properties in Step 2, immediately apply all declarations which are not in a fight. You are left with a smaller list of properties which are in a fight.
Going property by property, resolve each fight by using the tournament rules.
And now you’re done!

Compare this to the classical (popular) way of explaining CSS cascading described in Chapter 9 of the book:

Parse the CSS and construct the CSSOM.
“Cascade” rules through the CSSOM down to all elements, keeping track of which rules apply to what element using a tree.
From the tree generated in Step 2, apply all declarations to their associated node on the tree.
If there are any conflicts between properties, resolve the fight by comparing specificity scores.

The disadvantage of the top-down model is it does not help us debug CSS issues with individual elements. In the top-down model, we must go through the entire CSSOM to figure what styles are associated to a specific HTML element, and we can’t easily visualize the CSSOM tree in our heads.

In contrast, it’s much easier to focus on one individual element and ask, “what CSS rules apply to you?” then go off and find those. In fact, the developer tools in your browser allow you do exactly this using the “Inspect” or “Inspect Element” feature, which will helpfully find all the rules associated with an element without you needing to go through the entirety of your website:

a {
  color: orchid;
}
body a {
  color: seagreen;
}
.command {
  color: royalblue;
}
a.command {
  color: sienna;
}
a[href].command {
  color: aqua;
}
#lasers {
  color: hotpink;
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

<body>
  <a href="/" class="command" id="lasers">
    Activate lasers!
  </a>
</body>

All CSS rules that apply to the inspected element show up conveniently in a list in the sidebar:

Even though it’s called “Cascading Style Sheets”, I like to disregard the whole “Cascading” concept and just think about it in terms of each element’s specificity score, and how that affects the outcome of the tournament.

After the Tournament

Order of elimination

Something cool you may have noticed when you opened the developer tools panel: the list of CSS rules we see is ordered according to where they finished in the tournament!

You can think of this panel as a “leaderboard” for the tournament, where the 1st place winner of the tournament shows up at the top, then the selector below that is the 2nd place winner, and so forth.^[3]

This becomes clear when you use the panel to disable styles. You can click on the checkbox beside any declaration to enable or disable it. If I disable the declaration that won 1st place, then the 2nd place declaration is the “winner” of the tournament instead, so it becomes the style that is applied to the HTML element.

You can take advantage of this ordering when debugging. To find a specific declaration, you should start at the top and then work your way down to understand what’s going on, because it’s more likely that the final property that survived the tournament is near the top.

Once you find the declaration you’re looking for, you can stop there and you don’t need to continue scrolling down to the bottom, because anything nearer the bottom will have already lost the tournament long ago, meaning that you’re wasting your time if you keep scrolling—especially when debugging a large website with thousands of styles.

If you’ve scrolled all the way to the bottom and still can’t find your declaration, remember to check the user agent stylesheet in the gray area! It may be that you forgot to style your component and the default style is being applied.

Beyond Cascading: CSS-in-JS

If you’re thinking to yourself, “this seems very complicated and a lot of work to keep track of”, I agree with you!

To address this, the community invented CSS-in-JS libraries and inline style frameworks. Cascading, selectors, inheritance, and specificity are some of the hardest concepts about CSS to understand, so lots of developers sidestep the problem by using a library which abstracts away all of this, so you never have to worry about it again. These frameworks also give you other benefits such as code modularity (by removing the CSS global scope) and the ability to hook into automated tests.

For more info about the benefits of a CSS-in-JS library, I recommend watching this talk by Max Stoiber.

Inline style frameworks highlight why you should not learn by memorizing knowledge from dogma. Some experienced developers have a visceral negative reaction to hearing “inline styles”, because they were taught early in their career the best practice to “never use inline styles”. Even I told you not to do it in Chapter 6 of the book!

Indeed, “never use inline styles” was a best practice a long time ago when it made HTML hard to read, hard to debug, and hard to change. However, the technology chugs along and eventually upends the assumptions that lead to these “best practices”. New assumptions lead to new best practices.

Inline styles are only painful when you write them by hand—but if you use a CSS-in-JS library to manage your inline styles for you, these downsides disappear, and you are left only with the advantages of code modularity, automated testing, and simple management that works hand-in-hand with a front-end JavaScript framework such as React.

If you are stuck with the dogma of “never use inline styles”, you won’t have the curiosity to explore what it means when the original assumptions changed. This is why I’ve structured this book to encourage you to learn to reason for yourself using the Five Steps to Painless CSS.

After you’ve learned a framework like React, Angular or Vue, you can come back and learn a CSS-in-JS library to use in your projects. As of this writing (in 2019), the most popular framework that I recommend for CSS-in-JS is Styled Components.

So, if you don’t have to use the cascading or specificity rules by installing a CSS‑in‑JS framework, why learn cascading or specificity at all? I think these are still useful concepts to learn because while your CSS-in-JS framework can protect you from the perils of cascading 99% of the time, the 1% of the time when you encounter a horrible career-ending bug, you can have the confidence to fix it and save your career instead (true story).

Keep in mind that not every website uses a CSS-in-JS framework, and for smaller websites you may not want to go through the trouble of setting up one, especially because it requires integration into a larger JavaScript framework such as React or Vue. In these situations, plain vanilla CSS works simply fine.

Finally, the last reason why I think it’s still useful to learn all this, is because… umm well… “cascading” is right there in the name: Cascading Style Sheets.

I hope you enjoyed this article, and that it demystified CSS specificity and cascading for you. This article is an excerpt from Painless CSS, a book and video course that teaches you CSS from first principles. You can learn more at www.painlesscss.com

Top 10 most deadly CSS mistakes made by new and experienced developers

Bill Mei — Mon, 29 Jul 2019 19:00:18 +0000

For years, I've seen numerous engineers working at my clients make the same common mistakes with Cascading Stylesheets (CSS). Even the talented, experienced engineers make these mistakes despite their expertise across broad technical areas because they haven't dedicated time to learning CSS the same way they dedicated time to learning algorithms in university.

I think CSS is perceived as an unintuitive and difficult language to work with because of these common mistakes that thwart most developers when they try to write CSS. If you can avoid these mistakes, you'll see that CSS is actually a straightforward, easy-to-understand language that doesn't deserve its reputation.

What follows are the top 10 most deadly mistakes I've seen engineers make throughout my consulting engagements, listed in increasing order of severity. The more serious the mistake, the harder it is to recover from without a complete re-write of the codebase.

Mistake #10: Following the DOM when writing selectors

Let's take this HTML page as an example:

<body>
  <div class="container">
    <div class="main-content">
      <div class="blog-row">
        <div class="blog-col">
          <section>
            <article>
              <a href="#">This link is not bold</a>
              <p><a href="#" class="bold">This link is bold</a></p>
            </article>
          </section>
          <section>
            <a href="#">This link is not bold</a>
          </section>
        </div>
      </div>
    </div>
  </div>
</body>

Some developers like to maintain a minimalist ethos where they try not to clutter up the HTML with lots of classes, by using the DOM structure as a guide to writing CSS selectors, so that their selectors follow the structure of the DOM tree like so:

🚫 Mistake

body > .container > .main-content > .blog-row > .blog-col > section > article > p > a.bold {
  font-weight: bold;
}

Preprocessors like SASS make this especially tempting because they make it easy and natural to nest selectors:

🚫 Mistake

body
  .container
    .main-content
      .blog-row
        .blog-col
          section
            article
              p
                a
                  font-weight: bold

However, this "minimalism" is misguided because by keeping the HTML “clean”, you end up cluttering the CSS and making it harder to understand, debug, and change. Your CSS becomes inflexible, as the long combinator chains force the CSS to take on the job of replicating the structure of HTML, but that’s not the job that CSS is supposed to do.

The job of CSS is to provide styling, and the job of HTML is to provide the structure. Just because the DOM tree looks one way does not mean the CSS should match it—the way you write CSS should be totally independent of the HTML. If you decide to change the structure of the HTML, then you’ll have to go back and update every combinator chain you’ve made in CSS as well, which is painful, error-prone, and adds unnecessary work.

Instead, I recommend using targeted classes on your elements whenever possible. If you need to cherry-pick a specific element out of your page, a class selector can do the job just fine:

✅ Correct

.bold {
  font-weight: bold;
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

Now if you ever change your mind about the ordering of the links on the page, you don’t need to re-write your entire CSS rule. You can simply move the .bold class onto the element you desire.

Luckily, this mistake is less of an issue if you use a CSS-in-JS implementation. However, CSS-in-JS is not yet widely adopted (as of 2019) and I still see unnecessarily chained selectors in codebases that do not use any preprocessors.

More generally, you should avoid overly targeted or overspecified selectors, and also avoid using !important. The CSS Specificity Tournament gives us an intuitive sense of why overpowered selectors are bad. If a selector is enormously powerful in the tournament, it wins faster and at earlier rounds, meaning the only way to beat a powerful selector is to write another selector that is even more highly powered.

Mistake #9: Ignoring SEO when writing HTML

Search Engine Optimization (SEO) is not simply a task you offload to your offshore marketing team once you're done coding. SEO should be something you take into account while you're coding, especially because some factors that affect SEO are hard to change once they are already implemented in production; for example, your site's URL scheme or your services architecture.

One thing that impacts SEO in the HTML itself is making sure you use semantic tags, because your choice of tags affects how search engines understand and rank your content. If you want to show up near the top of the search results, choosing the right tags is one of the first places to start.

For example, let's say you are writing a blog post about real estate prices in Toronto. You could just put everything into <div> elements; however, a <div> is a generic, unsemantic tag which doesn't imply any inherent meaning in the content. Instead, you should pick a more specific, semantic tag such as <article> to contain the article, <nav> to contain some links to other blog posts, and <table> to contain the tabular data about real estate prices.

The advantage of choosing more specific, semantic tags over generic, unsemantic tags is that you are giving search engines more information about your website, which allows the search engine crawler to better understand and deliver content relevant to a reader's search query.

Let's take a look at headers, for example. There are six potential header tags, in order from most important header to least important header:

<h1>
<h2>
<h3>
<h4>
<h5>
<h6>

<h1> is your most important header, because it is a special signal to the search engine that this is the headline or title of your content (there is also the <title> tag, but most search engines take both into consideration). Additionally, if your user is vision impaired and uses a screen reader, most screen readers know to read <h1>s aloud straight away because it is assumed that this is the headline of your content.

This means that if you use an <h1> for anything that is not a headline, or if you have more than one <h1> on a page, the search engine will be confused, and your "real" headline may not show up in the search results.

The exception to this is when you nest multiple <h1>s in different sections. Take the following example:

<article>
  <h1>My cool blog post</h1>
  <p>This blog is so cool!</p>
</article>
<footer>
  <h1>Contact Us</h1>
  <p>Tel: 867-5309</p>
</footer>

Even though there are two <h1>s on this page, the first one has a parent of <article> and the other one has a parent of <footer>. Since the search engine understands that the <article> is inherently more interesting and important than the <footer>, it can appropriately use the <article>'s <h1> tag instead of the <footer>'s <h1> tag to determine the headline. So in a certain sense, it matters who your parents are, to determine how important you are. Just like in real life. 😉

There are many more factors that influence your search engine ranking beyond the ones mentioned. To stay on topic in this article, I encourage you to read a book on SEO if you're interested in learning about this topic in more detail. (How do you determine what is the best book on SEO? I wonder if it makes sense to just grab whatever one shows up first on Google. xkcd.com/125)

Mistake #8: Using `px` units

Actually, using px units is fine in certain cases. The real mistake is using absolute instead of relative units.

We prefer using relative measurements such as em (The length of an Em), % (percent), rem (root-Em), and others whenever possible. This ensures that the website scales proportionally according to your choice of font, and according to the user’s choice of zoom level.

🚫 Mistake

p {
  font-size: 16px;
  line-height: 20px;
  margin-bottom: 8px;
}

✅ Correct

body {
  font-size: 16px;
}
p {
  font-size: 1rem;
  line-height: 1.25;
  margin-bottom: 0.5em;
}

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

The problem with using absolute units like px is that every user has a different monitor size, and their browser windows (viewports) also have assorted sizes. This is counterintuitive because in almost every other realm of our lives, like interior decorating, city planning, or baking, we always deal with absolute measures. But on the web, the canvas that we’re painting on will suddenly change proportions every time a new person looks at it.

This makes it impossible for your website to always have the same proportions everywhere, so you must try to place your elements in relative terms (brick B should be as big as brick A) instead of absolute terms (brick B is a 200px-by-400px rectangle); otherwise the available space on the screen does not scale appropriately to every window size. Relative units make this easy—px locks your design to a specific zoom level and makes your design hard to scale to different devices.

Mistake #7: Trying to achieve a “Pixel Perfect” design

More generally, “Pixel Perfect” design is a bad goal to aim for when writing CSS.

Modern websites must work across a variety of devices (mobile, desktop, tablet, and watches), of which there is a cornucopia of screen sizes, screen resolutions, operating systems, user settings, and JavaScript engines that interfere with your ability to render “Pixel Perfect” designs.

In my opinion, a cultish pursuit of “Pixel Perfect” design will cost you in significant extra code complexity to deal with these inconsistent rendering schemes (along with the increased risks of bugs that result from complex code) for a small benefit that will probably get washed out once the next generation of devices, operating system versions, and browser versions get released.

In practice, the only situations where it makes business sense to pursue this kind of design perfection occur when you are a large company like Apple or Google and have the resources (money) to pay large design teams to make 0.01% improvements in the design. But unless your business also makes $400,000 per minute, a 0.01% improvement won't earn you millions more dollars more year—instead, it'll just create unnecessary engineering complexity.

Don’t confuse a “Pixel Perfect” design for great design. Truly great design is about leaving an emotional impact on the user that lasts with them. It’s the delight they get when they unbox your product and the joy they get from engaging with your website. It’s not the adoration of your choice of a 16pt font instead of a 15pt font.

Mistake #6: Breaking the document flow

The tricky part about CSS is you can write different CSS code to achieve the same visual result. For example, to horizontally center an element on a page, you could use any of the following techniques, and they'll all look the same to the user:

Surround the element with   until it looks centered
Explicitly set the width and left margin of the element to a fixed value that makes it look centered.
Use text-align: center
Use margin: 0 auto
Use a combination of floated siblings and a clearfix.
Use a combination of position, left, and transform.

Which technique is best? Depending on your goals, it may be perfectly correct to use any of the above techniques.

Generally speaking, there are some rules of thumb we try to follow to select the best layout method.

First, we eliminate any technique that uses absolute measures instead of relative measures. This means #1   and #2 explicitly setting the width are out.

Second, we prefer techniques that do not modify the document flow over techniques that break the document flow. This is because elements follow the document flow by default, so if you break this default assumption, you'll make it harder for your co-workers (or yourself, 6 months from now) to understand what's going on. This means #5 float and #6 position are out.

More generally, we prefer techniques that require as little change to other things as possible. Keeping your footprint small helps you avoid sprawling, complicated code that is hard to maintain.

Technique #3, text-align: center works only on inline elements, so we'll choose #3 whenever our HTML is already an inline element, and we avoid the extra need to add a display: inline CSS declaration.

Technique #4, margin: 0 auto works only on block elements, so we'll choose #4 whenever our HTML is already a block element, and we avoid the extra need to add a display: block CSS declaration.

Breaking the document flow too frequently (e.g. overzealously using float) increases your footprint and makes your layout harder to understand. When there are multiple options to write CSS code to achieve the same visual result, we prefer using techniques that have a smaller footprint.

Mistake #5: Not separating design from layout

The job of CSS is to provide styling, and the job of HTML is to provide the structure. Generally, you should first write HTML in a way that captures the information hierarchy of the page, ignoring any design concerns. Afterwards, you can add CSS to make things look nice.

While HTML provides structure, it cannot always position elements on the exact spot of a page you want it to appear. Thus, you can use CSS to scaffold the correct layout of the page so that the elements appear in the right location. Once an element is placed into the right place on the page, it’s easy to dress it up after and make it look nice without worrying about its location, so you should think of the “layout CSS” as a different job from the “lipstick CSS”.

🚫 Mistake

.article {
  display: inline-block;
  width: 50%;
  margin-bottom: 1em;
  font-family: sans-serif;
  border-radius: 1rem;
  box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}
.sidebar {
  width: 25%;
  margin-left: 5px;
}

<div class="article"></div>
<div class="article sidebar"></div>

✅ Correct

/* Layout */
.article, .sidebar {
  display: inline-block;
}
.article {
  width: 50%;
  margin-bottom: 1em;
}
.sidebar {
  width: 25%;
  margin-left: 5px;
}

/* Lipstick */
.card {
  font-family: sans-serif;
  border-radius: 1rem;
  box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}

<div class="article card"></div>
<div class="sidebar card"></div>

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

Making sure to keep the job of "lipstick" separate from the job of "layout" is also known as separation of concerns, and this is a common software engineering principle that helps keep our code maintainable and easy-to-understand.

We want to use the appropriate tool for the job because separating our CSS in this manner makes it easy to move an element to another part of the page without smudging the lipstick, and also makes it easy to change the color of the lipstick without disrupting the layout. Mixing the two forces us to do both jobs every time we add a new feature, even if it only warrants one job.

Mistake #4: Designing for desktop before mobile

Gone are the days where mobile websites were an optional extra tacked on by development agencies to pad invoices. Most people now surf the web on their phones and it's common to see more than 50% of your web traffic come from phones and tablets.

People love to extol the "mobile first" philosophy but they forget that "mobile first" implies desktop is a second-class citizen. Instead, the "mobile first" champions behave in the opposite manner, by writing code for desktop first and then later trying to cram the site into a phone. They use @media queries to handle the exceptional cases on mobile, but really desktop should be the exceptional case.

In this mobile era, your users first find you through their phones, and then only later do they upgrade to the desktop experience if they like your product enough.

But does mobile truly come first in the minds of your designers, developers, and product managers? Do you code the mobile site first and then later build the desktop version? Do your designers create wireframes and mockups for mobile before they create wireframes and mockups for desktop? Do you perform A/B testing and solicit user feedback on the mobile version of your website before you test the desktop version?

🚫 Mistake

.container {
  width: 980px;
  padding: 1em;
}

@media (max-width: 979px) {
  .container {
    width: 100%;
    padding: 0.5em;
  }
}

✅ Correct

.container {
  width: 100%;
  max-width: 980px;
  padding: 0.5em;
}

@media (min-width: 980px) {
  .container {
    padding: 1em;
  }
}
/*
  Notice how this also avoids needing to
  write 979 instead of 980, so you don't
  need to search for two different values
*/

These code samples come from Painless CSS, a book and video course that teaches you CSS from first principles. You can download the full repo with all 60 code samples and solutions in the course.

That your users are mostly mobile users is not the only reason to design and develop for mobile before desktop. The primary reason is that it's fundamentally easier to develop for a small screen before scaling the design up to a large screen, and not the reverse. You can always make existing elements bigger to fill a blank space on a larger screen, but it's trickier to remove elements from a large screen to make them fit into a smaller one.

Image credit: Zurb

If you ship a mobile website without a desktop site, it will cost you $X to build now, and then $X again to add a desktop site later. But if you ship a desktop website without a mobile site, it will cost you $X to build now, and then $2X to add a mobile site later. This is what people mean by "technical debt": you are paying a lower cost today, at the expense of paying a greater cost over the long run.

Now, if you are blitzscaling, it may make sense to be "inefficient" and build only the desktop website to prove product-market fit with the understanding that a mobile site will cost more later, but this is a business decision. Engineers will prefer building the mobile site first even if it doesn't always make business sense, so adjust this advice accordingly depending on your stage of growth.

Mistake #3: Not using a naming scheme

Namespaces are one honking great idea -- let's do more of those!
— PEP 20: The Zen of Python

It's always exciting to dive straight into writing code without thinking carefully about your naming scheme for variables. For example, do you call it img or image? blog-img or img-blog or blog-image or blog-img? If you call it blog-img, will you later agree on ad-img and thumbnail-img?

It seems minor, but CSS is harder to refactor than other languages because we currently don't have any static analysis tools for CSS that let us perform automated refactoring/renaming. CSS classes can be dynamically added, removed, and constructed using JavaScript, so it's impossible to find "unused" CSS selectors—just because a snippet of CSS isn't being used in one state of one page, doesn't mean it's not used ever. BEM doesn't solve this problem if your team can't agree on whether to call it .center, .centre, .centered, .text-center, or .align-center.

This problem is partially solved by using a CSS-in-JS library because these frameworks remove the global scope of CSS and encourage you to keep styles alongside their associated components. However, CSS-in-JS is not yet widely adopted (as of 2019), and I still have on my wishlist a static analysis tool for CSS—theoretically, CSS-in-JS should make it possible to implement one for the first time.

This is also partially solved by using a design system, where you agree on a fixed set of variables for colors, spacing, fonts, etc., but unused classes have a tendency to persist because we don't have an automated way to identify and remove them.

Developers are rightfully hesitant to remove anything that might break the website, so they err on the side of caution and prefer to grow the waste pile. Worse, unless you are diligent about promoting and clearly communicating your design system, it may simply get ignored as your co-workers avoid reading your documentation and continue in their old habits.

Mistake #2: Not reading the documentation

It seems so easy. Just install Bootstrap and you are good to go right? Unfortunately, a CSS framework can often cause more problems than it solves if you don't really understand it, and accidentally go against its principles. No matter if you are following an open-source design system like Bootstrap, Material Design, Foundation, or your company's own home-grown design system.

One of the best things I ever did for my career was to just set aside 4-8 hours to read the official documentation in its entirety every time I wanted to use a new programming language or framework. As in, not skimming the docs or only searching for keywords that are relevant to my immediate needs, but actually reading it cover-to-cover like a book.

For example, before I started using Bootstrap, I set aside 6 hours to read its documentation in its entirety. This has saved me countless hours in implementation later, especially in avoiding grid nesting issues that seem to be endemic, because those who skipped the documentation didn't realize that you're not allowed to nest Bootstrap containers.

Diligently reading the documentation is important because many frameworks require you to un-learn the muscle memory you picked up from previous frameworks, and you can't know where the pitfalls are until you've read the whole manual. For example, component inheritance was a common pattern in older front-end frameworks such as Backbone. However, newer frameworks such as React work best when using composition instead of inheritance, but you won't realize this if you skip the docs because you'll just default to using the inheritance patterns that you're used to.

More generally, it's dangerous to get trapped by the muscle memory you've developed from old technology, which leads us to the final fatal mistake:

Mistake #1: Not following a systematic plan to learn CSS

Technology is ever-evolving, and the only way to stay relevant is to follow a consistent plan of learning and improving.

It's dangerous to learn by memorizing knowledge from dogma. Some experienced developers have a visceral negative reaction to hearing “inline styles” because they were taught early in their careers the best practice to “never use inline styles”.

If you are stuck with the dogma of “never use inline styles”, you won’t have the curiosity to explore what it means when the original assumptions changed. It's important to use a systematic, structured plan to learn CSS from the ground up and not just search Google for tutorials that only focus on surface-level practices.

Unfortunately, I tried looking for free online resources that help you learn CSS in a structured, systematic way, and there simply aren't any good resources out there. The existing CSS resources either are too technical and assume you already know how browser C++ rendering engines work (which is not at all approachable), or they present only quick and dirty tricks instead of teaching you foundational principles.

Because there is no good resource that gives you a solid mental model for how CSS actually works from the ground up, you’re left copy/pasting stuff from Stack Overflow and hoping it works. This leaves lots of people with a patchwork knowledge of CSS, knowing just enough to solve specific bugs that arise, but feeling completely helpless when faced with a hard-to-understand bug that seemingly takes hours to fix.

Frustrated by seeing people repeat the same mistakes with CSS in my years of consulting for software startups, I decided to take matters into my own hands and write my own resource. I created a course, Painless CSS, to provide a comprehensive, first-principles guide to learning CSS the right way and to give you the real skills you need to write professional-grade CSS.

The secret is that CSS is actually a straightforward language once you are equipped with the right mental models. I created the Painless CSS course because I want CSS to finally shed its undeserved reputation and rise from the ashes as the beautiful programming language that it is.

I hope you enjoyed this article, and that it gave you a sense of how to avoid the top 10 most common mistakes I see people make when they write CSS. There are many other mistakes I see people make with CSS—you can learn about them all in detail, and how to fix them in the Painless CSS course here: www.painlesscss.com.

In the meantime, I hope this article was helpful to you and inspired you to take your plan for learning CSS seriously, no matter if you decide to purchase my course or someone else's. It's never been a more exciting time to learn front-end web development, and I wish you the best in your programming journey.

Forem: Bill Mei

The Definitive Guide to CSS Cascading and Specificity

Competitor 1: Maroon Malamute

Competitor 2: Sapphire Shepherd

Competitor 3: Purple Poodle

Competitor 4: Teal Terrier

Tournament Rules

Round 1

Round 2

Round 3

Shortcut: Specificity Score

Competitor 1: Maroon Malamute

Competitor 2: Sapphire Shepherd

Competitor 3: Purple Poodle

Competitor 4: Teal Terrier

Specificity Rank

Exceptions to the Tournament

Inline Styles

!important

Tied until the end

Inheritance

Universal Selector

Non-Participants

Combinators

The Painless CSS Tournament

After the Tournament

Order of elimination

Beyond Cascading: CSS-in-JS

Top 10 most deadly CSS mistakes made by new and experienced developers

Mistake #10: Following the DOM when writing selectors

🚫 Mistake

🚫 Mistake

✅ Correct

Mistake #9: Ignoring SEO when writing HTML

Mistake #8: Using px units

🚫 Mistake

✅ Correct

Mistake #7: Trying to achieve a “Pixel Perfect” design

Mistake #6: Breaking the document flow

Mistake #5: Not separating design from layout

🚫 Mistake

✅ Correct

Mistake #4: Designing for desktop before mobile

🚫 Mistake

✅ Correct

Mistake #3: Not using a naming scheme

Mistake #2: Not reading the documentation

Mistake #1: Not following a systematic plan to learn CSS

Mistake #8: Using `px` units