CSS Specificity is a Rat-Hole

Oh yeah, except for that guy. You might think, well, if it gets that hairy, I can just throw !important on there, right? If I know I need my button’s margin to be at least this big, or my whole plugin will be busted, I can just force !important on there, and everything will always be fine, right?

Yeah, !important rules beat errrrrrbody. Well, except…

You know how they say the easiest way to drive down mountain switchbacks at night is to turn off your headlights and follow the stripe right in the middle? And hope nobody’s doing the same thing in the other direction?

Well, !important declarations win out over everything except other !important declarations, then we’re back to the same rules as before. Important rules don’t escape the model of specificity, they just increase the value.

Specificity escalation

In the life of a site, the specificity of its CSS tends toward infinity.

Hitting every branch

I saw students in my introductory web class do this a lot: given some markup like this, if they wanted to style that selected-item link down there, they’d start like this:

…start at the top of the DOM tree, then kinda

…jump off the top, and hit every branch on the way down.

It’s a misunderstanding of how the cascade works—you don’t need those qualifiers or any of the elements in the middle!—but it’s distressing how often you see production code that looks like this. You never know, though, if the developer was misunderstanding, or just trying to override somebody else’s crazy selector.

Why not?

I mean, what’s wrong with that selector? It’s certainly unambiguous, right? Come hell or high water, you’re going to style that link.

If an existing style is overriding your new style, the only way to defeat it (aside from deleting it altogether) is to make your new rule more specific. It’s an arms race.

So if you take that selector we just saw, and, let’s say it’s setting a line-height. If you need to override that line-height for some versions of your nav links, there are two ways to go:

You can add an adjacent class on the node itself

or you can add another wrapper around some part of it, and use that as your specificity hook.

But what happens when that rule needs an exception? The only way out is to get more specific.

Hard to reason about.

Instead of having a conceptual unit that’s composed of other conceptual units, whose styles are more likely to live in one place,

you have a mishmash of things reaching beyond each other, and it’s hard to think of them without also thinking of their entire contextual universe.

In this case, my example was simple to fit on one slide, but usually, the more you rely on the cascade for details within a module, the more code you have to keep in your head when you think about that module, code that might be spread all over the place. It’s much easier to debug and simplify styles that you can see on the screen at once, or at the very least in one screenful of Dev Tools sidebar.

Tied to a particular DOM structure

Taking our same example, if our DOM structure is on the left, with that same selector broken into corresponding pieces on the right, this is the “why bother if it works” state.

But let’s say you realize you’re going to have multiple nav elements, and the thing you were calling #main is really a header, so you change your markup…

Oops. Your selector’s broken, and you have to go fix it.

Or, in our original structure, the list had an active class that was applied when the user took a specific action, let’s say opening a drawer. If your JavaScript benefits from marking the parent div as active instead, and you change your script…

Oops. Your selector’s broken, and you’ll have to go fix it.

You want to have confidence in the changes you make. You want to be sure that reasonable changes to your markup or your scripts aren’t going to break other, unrelated stuff.

WordPress and specificity

These problems are particularly noticeable in the WordPress community.

I want to show you some examples I pulled from literally the first three themes I chose at random from the wordpress.org directory and ThemeForest. I’m not trying to shame the developers that wrote these—we don’t know what constraints they were under, what support ticket they were closing, or who else’s code they were fighting.

That’s a really deep selector, right? I like this one because if you read it aloud it kinda makes a song.

You read these right to left, so let’s see: we’re styling the thing called “dropdown-toggle” when it’s the direct child of the list item called “dropdown” and “open” and “active” inside the thing called “nav” inside the thing called “navbar” inside the thing called “sticky-enabled”. This looks a little like our “hitting every branch” example, doesn’t it? It seems like .nav might always be inside .nav-bar, so you could probably omit that selector… unless you’re stuck in a specificity war.

Two ids! They’re really serious about this one. Again, I’d guess that #wp-admin-bar-tc-customizr-help is always going to be inside #wpadminbar, and some of these selectors are overly specific to fight other people’s CSS.

In this one, you can kinda do CSS forensics, and see where they started and where things went sideways a bit. I’d be very surprised if the initial selector included that .alignright. More likely, there were styles for a general case, and adding an .alignright wrapper somewhere had the unintended side effect of breaking them, and this fix became necessary.

Part of the reason we see these kinds of selectors in WordPress is cultural norms and the way the old defaults behaved, and at least part of it is due to architecture. Here’s what I mean by that:

Let’s say a given page template is made up of a bunch of different partials, simplified here.

There’s kind of a natural inclination, when you know the partials are going to change, to have each one identify its outermost container with a class or id,

then turn those into a selector.

Then, when one of the partials changes, you end up changing that piece in the selector to match, if you want to style it differently.

So it’s easy to get into a pattern where you’re mirroring the easy-to-change parts in your templates, and the nesting of your templates, in your CSS selectors.

One one hand, it’s good. It’s easy to get up-and-running on the PHP side. It’s an easy, built-in hook for style changes.

On the other, it’s not so good. You’re starting off with crazy specificity.

How do we avoid all this?

Reduce unnecessary specificity.

Start simple, take baby steps

Start with the most brain-dead simple selector, and see what breaks. If you’re starting a new stylesheet from scratch, you might be fine (and also, lucky you). For instance, in our example, start by trying the class on the node itself:

If something does break, and it’s because of something higher up in the stylesheet, resist the urge to go nuclear with your selector, and take the smallest sensible step toward greater specificity.

Whichever conceptual unit you’re trying to style, try to move one additional conceptual unit up on the hierarchy. Refresh, see what’s still broken, repeat. A good candidate in the example could be

since they’re really part of the same larger unit.

Now, one antipattern here would be to introduce a selector from an ancestor that’s merely incidental, like .grid-four or .alignright. Try to keep it to selector that are really part of the larger context, rather than things that just happen to be in the tree. Baby steps.

Don’t fear the markup

I think a lot of us were kinda broken by the CSS Zen Garden. If you’re not familiar with it (and I guess it did relaunch a few years ago, so it’s still a thing), the idea was that using this one page of standard markup, designers would submit stylesheets that showed the power of CSS by drastically changing the layout. For instance, this is the same page, same markup, different stylesheet.

In a lot of ways, this set great examples, giving web designers a lot of inspiration for interesting ways to use standard, mostly-cross-browser CSS to do interesting things. In a way, though, it set a bad example by teaching designers to contort their stylesheets to jump through hoops without touching the HTML, and a lot of people still do this. It’s a really bad habit, especially if you’re working with a CMS, where you can serve thousands of “pages” from a handful of easily-editable templates!

So get in there! Add helpful class names, create good names for things. Add wrappers if they help, change the order pieces are nested in. Help yourself out.

Some people get freaked out by defining pieces of a module with multiple class names, for some reason. You see people bring up the word semantic.

For years we were promised that if we were good, the browser fairies would intelligently glean all sorts of metadata from our markup and our classes, and synthesize whole new arrangements of data, and let the user search… it’s never happened.

“Meaningful” class names are only useful as far as they help you organize parts of your site into conceptual units. Classes and stuff are there to help you. Well, unless you’re specifically dealing with microformats, but that’s a different talk.

Don’t be afraid to change the markup if you can.

Use explicit server-side logic.

When you’re building your selectors like we saw before, there’s an implicit logic behind what you’re trying to select, and why. There’s a rule hiding in there, but you can only make it out in the right context, by seeing the selector with the other ones it’s trying to override.

Wow, you say, “If only there was some kind of language I use could use to help me make decisions about processes programmatically! Some kind of theoretical programming language!”

Instead of having your which-meta-thingie-are-these-selectors-styling logic spread out in the structure and contrast of the selectors, get that logic into a function and make it explicit to the next person that comes along.

It’s at least one step closer to going from something like this

to something like this (which, by the way, gives you the opportunity to name things well):

Don’t accidentally the whole specificity

If you’re using preprocessors, it’s really easy to accidentally introduce complexity.

I want to show you something I found on a project recently. A site I’m working on was having seemingly random problems in older IE (big surprise), and it turned out we were blowing through the budget of 4096 selectors old IE let you have in a stylesheet. Even if you’re concatenating all your stylesheets, that’s a lot of selectors. So I copied out the generated CSS and took a look in my editor, and this is what I saw.

I tweeted this a few months ago, and you might have seen it. Terrible and wonderful, right? Kinda awe-inspiring? My favorite part is when I was scrolling down to this hunk, I could see this mass of text coming up in the miniview like the boulder appearing behind Indiana Jones.

But what happened here was the grid framework included a SASS @extend on the class .last, and that class name got used elsewhere in the styles. Add a few mixins, and one line of SASS has Sorcerer’s Apprenticed us to a stylesheet full of brooms.

So be careful of these kinds of nightmare selectors. Check your preprocessor’s output.

Strive for simplicity, as always

1. Start simple, take baby steps.
2. Don’t fear the markup.
3. Use explicit server-side logic.
4. Keep an eye on your preprocessor.

But most of all,

Thanks!