Lesson Weekend

We've all been there; a CSS style isn't showing up in the browser. Perhaps we wrote a rule to turn certain line of text canary yellow, but it's still grey! Or maybe we centered an image in the DOM, but it's still pulling to the left! Things get considerably more complicated when using animations and transitions, or when the CSS we write is not the CSS that shows up in the browser (we'll work with this in a couple weeks).

The good news about every bug is that computers only ever do what they are told. At least...for now...

This lesson will walk through helpful tools and tips to keep CSS under control when it's seemingly staging a coup d'├Ętat against your sanity.

CSS Debugging Process

1. Start at the Wall

Have you ever spent time tracking down what you think is a complex error, only to realize you were just viewing the wrong document, missing a closing bracket, or not reloading your project in the browser? Ordeals like these can be prevented by "starting at the wall".

"Starting at the wall" means if something isn't working as expected, we begin ruling out the most basic explanations first. (Similar to Occam's Razor.)

We start at the very beginning of the list of expectations that make us think our code should work, and question each one. These can be things like "Is my computer even plugged in?", "Is the keyboard registering keystrokes correctly?", or "Am I viewing the correct page, document, or project in the browser?" (That last one -- Writing CSS rules in the wrong stylesheet -- Is actually really common!)

(Note: If you use the debugging tools below before completing the basic checks explained above, you risk of wasting time. Always start with the basics!)

2. Isolate the Problem

Once we've started at the wall and double-checked all basic expectations, it's time tackle the next step: Isolating the problem.

MDN's articles on Debugging CSS and Debugging HTML describe HTML and CSS as permissive code. This means instead of being compiled (like Java and some versions of JavaScript) it's interpreted by the browser.

If a compiled language includes a syntax error, the program will fail to run and instead display an error in the console. But this isn't the case with HTML and CSS! You see, HTML and CSS can actually be written incorrectly, and the browser will still attempt to run it just fine. As explained in MDN's Debugging HTML:

HTML [and CSS don't] suffer from syntax errors because browsers parse it permissively, meaning that the page still displays even if there are syntax errors. Browsers have built-in rules to state how to interpret incorrectly written markup, so you'll get something running, even if it is not what you expected. This, of course, can still be a problem!

Fortunately Chrome's DevTools allow us to see CSS errors in the inspector, specifically the styles pane. Let's take a look:

Using DevTools with Warnings

Here's a stylesheet with the body of the DOM highlighted:

css without errors in styles pane

Notice that below the Elements pane is another pane with the Styles tab selected. Here we can see the CSS rules that have been applied to the DOM from any source. Including user agent stylesheets (CSS that comes from the browser itself), or our own stylesheet, styles.css.

See that CSS rule that begins with *, *:before, *:after in the image above? Let's intentionally break it to see what happens in the Styles pane. We'll remove a semi-colon like this:

*, *:before, *:after {
  box-sizing: inherit
  border: 3px solid lightSeaGreen;

After refreshing the page, Chrome did us the favor of pointing out which rules aren't being applied:

css with errors in styles pane

Not only can we see the effect in the DOM, but we can see where the problem has occurred (styles.css line 8) and what (generally) is wrong. In this case, because box-sizing: inherit is missing a semi-colon, the whole block rules isn't applying correctly.

Using DevTools without Warnings

But sometimes Chrome will not see any explicit typos or offer warnings, but our CSS still won't be displaying the way we expect! When this happens, we have to do you own deep dive.

Ideally, this should end with a confident declaration of the specific location of the bug. Even if you don't fully understand the bug, figuring out where to start investigating is an important middle step!

What do we mean by this? Well, instead of thinking "It's not working!" we're looking for something more like, "On line X the attribute Y is given value A. If I change it to B it acts like I think it should, but for some reason when the value is A it doesn't work." Or maybe "On line A I used selector X which should be more specific than selector Y used on like B. But for some reason the rules for selector A are still overwriting B."

The Styles pane is helpful for this too! There is a huge number of small tools we can use to dig through code to find the problem. In DevTools we can:

  • Change existing rules directly in the browser.
  • Write new style declarations in an existing rule.
  • Write new rules with new selectors.
  • Click DOM elements and copy/paste selectors.
  • Toggle whether rules are even being applied with a checkbox.
  • Click on the source line next to a rule and see the source code in the browser.

Required Reading: Inspect and Edit Page Styles

To learn about the list of functionality above, read the Inspect and Edit Page Styles article from the Chrome Developer Tools' documentation. It offers a good run down of the skills we'll leverage debugging.

Additional Debugging Tips

In addition to the general process above, here are a few more tips and tricks you'll likely find useful throughout the course:

Use Borders

Adding a bright and contrasting border to all elements helps provide a feel for how the various relational box models in a site are interacting. This is especially helpful when dealing with positioning or with collapsed parents.

Comment Out Code

If you are having trouble tracking down the problem code in the first place, comment out all the code you can and try to isolate the behavior you are looking to achieve. Then slowly add CSS back to your stylesheet a little at a time. Once you re-add the code that is breaking your stylesheet you'll know very specifically where the error is originating.

Avoid Errors Entirely with "Outside In"

Remember this "Outside In" thing? You can avoid most difficult bugs by following the two best practices spelled out in this lesson. Make sure to keep practicing them daily!

Lesson 6 of 36
Last updated more than 3 months ago.