Reading Time: 5 minutes

So you’re a back-end developer. You write .net or Java all day. You create Schemas and Templates in Tridion. It’s Friday. The front-end developers have signed off early and you just got a high priority bug. And it’s in the CSS. You hate CSS. What do you do?

First, be honest

Let’s admit that that you’re the wrong person to be debugging CSS. You architect the the project. You argue with content deployers and build GUI extensions. You’re not the right guy for writing or debugging CSS. You don’t even write the stuff!

Debugging CSS is hard enough when you do this every day. It’s even worse when you don’t. So be honest and admit that this is not your strong suit.

Now, I’ll be honest and admit that it’s not any easier for me.

 

 

Next, let’s understand what this language is

CSS is a style language. It’s probably closer to declarative programming or rule-based programming. CSS is to HTML what XSLT is to XML.

With this kind of language, does it make sense that there be compile errors and message logs? No, it doesn’t. The web wouldn’t be very user friendly if a page stopped working the moment it encountered an error in a stylesheet.

So it’s a good thing that CSS is a declarative language that can still be parsed, even when the browser encounters an error. That means that one mistake doesn’t crash the site!

Now, let’s, learn the parts of CSS

Let’s look at this:

.myClass {
padding: .25em 1em;
}

This is called a ruleset. A ruleset is composed of two parts:

• The selector: .myClass
• The declaration block: {padding: .25em 1em;}

A declaration block is composed of declarations. Each declaration contains two things:

• A property: padding:
• A value: .25em 1em

You come from a backend world. So look at declaration blocks like you would look at JSON; they’re key value pairs!

What does this mean for debugging?

That a problem could be in one of five places:

1. The ruleset: not formatted correctly, not present
2. The selector: not formatted correctly, not applicable to any element
3. The declaration block: not formatted correctly, not present
4. A property: not valid, not applicable to the element
5. A value: not valid, not formatted correctly

Then, we look at the cascades

Let’s talk about the “C” in CSS. The “C” is for Cascade.

There are many cascades. In CSS 2.1, there were three:

1. User Agent (the browser)
2. Author (what you write)
3. User (the person looking at the web page)

Now there are 10 cascades.It’s a bit more confusing.

But what it amounts to is that the CSS that you’re writing and debugging is in the middle. Your CSS comes after the browser’s, but before the end-user’s. Most of the time.

What does that mean for debugging?

• Some issues are from the user agent cascade (but this is rare)
• Some issues come from the user cascade (also rare)
• Most issues come from attempting to modify the cascade (use of !important, unnecessarily high specificity)

Keep in mind that !important was created so that we can intentionally to break the cascade. Any time it isn’t used with the intent of breaking a cascade (yes, there are valid reasons), it will cause problems. It is always better to use the cascade than to break it.

You use the cascade by incrementally increasing specificity.

Next, we analyze selectors

This is important for back end devs, because this fact is not intuitive:

The browser parses a selector from right to left.

When you write this:

#thisId .thisClass .thatClass div ul li a {
  color: red;
}

Do you know what the browser reads first?

a {}

Why?

Because, that’s what you’re styling.
Everything in front of is just a “filter” to speak of. And think about it:

Do filters improve performance? Do they decrease the likelihood of errors?

No. No they don’t.

JavaScript does not behave this way, by the way. Longer selectors can be helpful in JavaScript. After all, JavaScript selectors will be parsed left to right. But don’t write CSS selectors like you would JavaScript.

What does this mean for debugging?

• The longer a selector is, the more likely it is to not apply
• If a declaration block is not being applied at all, it is because of the selector (there’s nothing in the HTML for it to match)

Figure out when specificity matters

I could write a whole essay on specificity. But that won’t help you in debugging.A lot of the “facts” of specificity are just trivia that front-end developers use to test each other when we’re bored.

Specificity only matters

• If you have two matching properties,
• being styled in two different rulesets,
• whose selectors apply to the same element

e.g., this doesn’t matter. It’s different properties.

.someClass {
color: red;
}
#someID{
font-family: Arial;
}

But this could matter:

.someClass {
color: red;
}
#someID{
color: blue;
}

 

Only if this is also true:

<div id="someID" class="someClass"></div>

…but !important, yes?

Sometimes, people will opt to “break” the cascade with !important:

.someClass {
color: red !important;
}
#someID{
color: blue;
}

 

This is the wrong time for !important.
Whoever does that is a butthole.

What does this mean for debugging?

If a style is not being applied, but you know that the declaration block and ruleset are correct:

• The property is being overwritten in another ruleset with a more specific selector
• The property is being overwritten by a ruleset of equal specificity that occurs later in the stylesheet
• The property is being overwritten in another ruleset with an equal, or less-specific selector, but the property has an !important declaration

Browser-specific issues

So it’s not because the declaration block is wrong. It’s not because the selector isn’t applying. It’s not because of specificity. it’s because one browser is being different.

Whew boy.

• There are standards
• Browsers are supposed to follow standards
• Most of the browsers are pretty good about following standards
• IE7, 6 were not good about following standards
• IE8 followed html4 and CSS2.1 standards
• IE9 kinda followed some HTML5 and CSS3 standards
• IE10 was auto-updating, so each version of IE adopted more HTML5 and CSS3 standards
• Microsoft gave up after IE11 and switched to Edge
• No one uses Edge

What does this mean for debugging?

You’ll need whisky. Lots and lots of whisky.