3 Techniques for teams  to tame their CSS beast

3 Techniques for teams to tame their CSS beast

November 29, 2017

CSS is a beast. It's a mean, ugly beast. It's a beast that's hard to maintain and keep organized especially as the scale of your project increases. If you relax and don't keep an eye on it, it ends up running rampant. While it can be tough taming the beast by yourself, it actually gets even tougher with the more people you add to the mix. You'd think that multiple people could team up on the beast. But in reality, the CSS beast thrives against teams. Teams can make it a fair fight, however, by adhering to these 3 CSS taming-techniques:

1 Keep CSS specificity as low as possible
2 Name classes well
3 Comment your code relentlessly

1 – Keep specificity low

If you’re like “specifici-whaaat?!?” then check out Specifics on Specificity to get a good baseline. Basically tho, specificity determines which selector wins when two or more CSS selectors are targeting the same element. The selector with the highest specificity level will take precedence. The trick is to never add unneeded specificity.

Some common techniques include not over-nesting your selectors, not using ID’s, and not using !important. Any of those will surely enrage your CSS beast. Avoiding those though is common sense. It’s basically like saying avoid bears and lions. Of course you’re going to do that. So, here are a few situations you might find yourself in where you’re tempted to over nest, use ID’s, or use !important with some clever tactical approaches to avoid extra specificity.

2x powered classes

What do you do when you need to override a class, but the class you need to override is below where you’re writing your override class? Order of selectors has an impact in CSS. When two equal weight selectors target the same element(s) the one that comes later takes precedence. So if you’re trying to override a selector that comes later in the CSS, then you have to bump up the specificity of your override selector. Well you could move your override below the thing its trying to override. Or, you could prefix the override selector with an ID to boost specificity. Finally, you could chuck on an !important keyword and call it a day. Instead of moving the override selector to an arbitrary place, or drastically dialing up the specificity, another approach would be to lightly increase the power of the selector like so: .override.override. This will double up the specificity but not nearly as much as prefixing with an ID or adding the !important keyword.

the ID fail-safe: attribute selector

Sometimes you’re in a situation where you may not have access to the markup to add a class but you need to style a specific element and all it has is an ID. This is that situation where a beast is right behind you and you know he’s there. The only thing that can stop him is that AK47 in your back pocket — an ID selector like so, #mainContent {}. You reach for it, then you realize you have a slingshot that is equally effective in neutralizing the threat. The sling shot is something called an attribute selector and it has the same specificity as a class. So instead of using #mainContent {} you can instead use [id="#mainContent"] {}.

ID’s and generic elements are a lethal combo

#mainContent h3 is a remarkably unwieldy and hairy selector. Because now every h3 is going to have an unnecessarily high specificity level. And you’re not going to be able to modify an h3 by adding a class to it. You’ll have to prefix every class with the ID, like so #mainContent .modifier. I don’t have a silver bullet solution to this, except just don’t do it unless you like doing things that will haunt you forever.

2 – Name your CSS classes well

“There are only two hard things in Computer Science: cache invalidation and naming things.” –Phil Karlton

Not only is naming stuff really hard, but on a large team, the importance of naming things well is magnified. Use names that accurately describe, aren’t too generic, and have personality. All three combined will result in a truly great name and a very domesticated CSS beast.

Accurate class names

After logging in to your Netflix on their website, before you can watch anything, it forces you to select a profile. It’s a gate that has to be passed through to start browsing tv and movies.

Netflix's profile selection screen
Netflix’s profile select screen is a gateway that must be passed through. They call it “profile-gate”.

Many of their class names on this page start with “profile-gate”. This is an accurate class name because this page is all about selecting a profile and serves as a gateway.

Avoid generic names

Generic names are going to run the risk of naming collisions. Large teams tend to have large products. If you are naming a class “widget” the chances are someone else is already calling something else “widget” somewhere else in your web application. Avoid overloaded names especially those based on appearance. For instance, “tile” and “card” may seem like great names, but in my opinion every rectangular thing in your web application could be thought of as a tile or card. Instead of calling something “card” try calling it “business-card” if its function is to provide contact information or “poker-card” if its function is to determine rank. This turns an overloaded name that doesn’t describe function into a more specific name that describes function rather than appearance.

Create names with personality

In The Language of Modular design, an A List Apart article by Alla Kholmatova, she mentions to draw from objects in the real world in order to create names that stick. “Billboard” for a component that reminds you of a billboard. And even “boss” and “minions” for the name of buttons. Boss being the big button that only appears once on a page. Whereas, minions are the smaller size buttons that can be used multiple times per page. You’ll know its a really good name, when the name also establishes smart rules for using those classes. These names have a bit of personality that going to help them stick better.

Naming your classes well allows team members to more easily understand your intentions and be able to contribute to an unfamiliar project much quicker.

3 – Relentlessly comment your CSS

Most, if not all, well-maintained open source projects tend to have two things in common: lots of contributors and lots of code comments. When on a team, treat your CSS like it’s an open source project and comment the heck out of it. This last CSS-taming technique thoroughly neutralizes every beast.

A screenshot from Bootstrap shown above, thoroughly commented.

Open source projects want people to jump in and contribute, fix the bugs they find, add features, etc. The thing that helps lots of random people contribute is well commented easy to understand CSS. Large teams also want existing team members to contribute to any project at your company, and new team members to jump right in to the code base without lots of confusion. As the CSS beast thrives on confusion, minimize that by commenting your CSS.

And I tend to really agree with that. Moreover, Harry Roberts puts it nicely:

“As a result of CSS not telling its own story very well, it is a language that really does benefit from being heavily commented.” –Harry Roberts, cssguidelin.es

Harry’s CSS Guidelines is a really great resource for teams writing CSS. He goes in to a lot of detail about commenting CSS as well as other great practices. Here are a few things from his white paper that really stand out as especially important as far as commenting goes.

Module comments

Comment different modules of your CSS using larger landmark comments to make things easy to find and add some information to that block that’s helpful. Like when it should and shouldn’t be used.

An example, assuming Less or Sass:

//Uno Card
//The uno card UI pattern is used 
//for features like community-based 
//movie rankings, also for critic rankings 
//and movie popularity
//Not intended for use with promoted articles, 
//instead use the article-fist-bump class

“Just a heads up” comment

Comment any clever CSS that may not be easy for others to understand.

.selector\ {
    margin-left: -2px; 
    //IE selector hack, fixes spacing issue in really old IE (fixes bug #1821)

Top of file

Comment the top of .scss or .less partial files to explain what those files do and what is meant to go in those files. This helps make sure that folks know what belongs in a given file, resulting in CSS ultimately being better logically grouped by file.

Table of contents (TOC) file

“An up-to-date table of contents provides a team with a single, canonical catalogue of what is in a CSS project, what it does, and in what order.” –Harry Roberts, cssguidelin.es

A TOC is helpful for listing each .scss or .less partial file and describing what should go in those files. The TOC serves as a signpost for helping developers determine the most suitable file for adding their CSS.

Self review

There is a really nice byproduct of writing a lot of comments. While developers are trying to reason about what they just wrote and explain it, it forces them to review their CSS, review their class names, and review their reasons for doing things. It provides the opportunity to refactor or improve CSS while it’s still fresh.

You can never have too many CSS comments as the beast really struggles to be a threat in a well commented codebase. Since the beast thrives in a disorderly and chaotic environment, the extra details and organization that a well commented codebase provides really is a buzzkill for the CSS beast.

Closing note

Ultimately, if you keep specificity low, name your classes well, and comment the heck out of your CSS, your team is going to turn your CSS beast into a well-mannered, orderly, and easy to update CSS codebase.

The CSS beast image credit courtesy of and created by Eliricon from the Noun Project

Mastering CSS: Book by Rich Finelli
Mastering CSS, the Book! Flexbox, Layout, Animations, Responsive, Retina, and more!
Mastering CSS, 2nd Edition, video course by Rich Finelli
Mastering CSS, Second Edition: 47 videos on how to make websites like a boss! Flexbox, Animations, Responsive, Retina, and more!
  • Rich

    And the more dispersed your team is with remote developers the easier it is for the CSS beast to get out of control. And the more relevant these three techniques become.

Back to top