5 min read

Object Oriented Programming is something you’ve probably heard a lot about. While CSS is not a programming language, you can still use Object Oriented principles to write highly maintainable CSS.

One problem I have when jumping into an already existing code base is figuring out how the heck everything is styled. What is the worst case scenario I’ve ever heard about? A project with over 100 important tags on various link classes all over the code base because an important tag was placed on the base[KB1]  of a tag[RJ2] . What happens when you inherit CSS files structured like this? Sometimes you’re good and make things better, but often times a combination of time line, other things on your plate and a little bit of laziness contribute to you adding things in to make the code base even worse.

What is OO CSS?

First off, what is Object Oriented CSS? How abstract should you get? These are some important questions.

One, Object Oriented CSS is abstracting.

Two, you shouldn’t be so abstract that new people coming onto the project have no idea what your classes mean. If you have a bunch of names like .blue, .padding-left-10, .big, .small, it’s basically making your CSS the same maintainability as if you had inline styles.

There’s a good balance between abstraction and practicality.

BEM!

I’ve used BEM on personal projects and with a team. I love it. I don’t want to go back to writing my CSS without using the BEM naming convention.

Here’s the basics: BEM stands for block__element–modifier

Block is the component you’re building. Element is the element of the component (example: header, text, image, icon, etc). Modifier is modifying a component.

The trick is you don’t want to do something like this: block__element–modifier__element or block__element–modifier–modifier.

If you’re using a preprocessor, you can break your files up into components so that each file deals with only one block. This makes it very easy for other developers joining a project to find your component.

Don’t go more than 2 levels deep. Keep your CSS as flat as possible, and it’s okay to have long class names.

The arguments against BEM include things like: “It makes my markup ugly.” I would rather have more maintainable CSS and HTML than pretty CSS and HTML. Also, after working with BEM for about a year now, the syntax has grown on me and now I find it beautiful.

If you’d like a more in depth view on BEM you should check out this great post.

How Does This All Fit Together?

You have to find out what works and what doesn’t work for you. I’ve found that I prefer to think of everything on my page as various components that I can use anywhere. I borrow a little from SMACCS and a little from BEM (you can read a lot more about both subjects) and I’ve created my own way of writing CSS (I use SCSS; you use what makes you comfy). I like to keep layout out of the equation when writing components (thanks SMACCS!). I’m going to use generic layout classes because everyone likes their own particular framework.

Basically you have a basic card that you’re trying to create. You create a base component named card placed in a file named card.scss or whatever.

Each component contains the elements and modifiers below them. I personally like to nest within my modifiers. A ‘large card’ should always have a .card__header that has a green background. I don’t like to make a class like .card__header–large. I keep both the .card class in addition to the .card–large class on my div. This way I get all the classes that a card has and also modify the parts I want to modify with a –large modifier. Different people have different opinions on this but I have found this works great in maintainability as well as ease of copy-pasting markup into various parts of your page.

Your CSS can look a little something like this:

  .card {
      color: $blue;
  }

      .card__header {
          font-size: 1.2rem;
          background-color: $red;
      }

      .card__header--blue {
          background-color: $blue;
      }

      .card__title {
          color: $green;
      }

      .card__author {
          font-size: rem-calc(20);
      }

      ...

  .card--large {
      font-size: rem-calc(40);
      
      .card__header {
          background-color: $green;
      }

      .card__title {
          font-size: 2.0rem;
      }
  }
Now for your markup:
  <div class="column">
      <div class="card">
          <div class="card__header">
              <h2 class="card__title">Hi</h2>
              <h3 class="card__author">I'm an author</h3>
          </div>
              
          <div class="card__body">
              <p class="card__copy">I'm the copy</p>
              <img class="card__thumbnail">
          </div>
      </div>
  </div>

  <div class="column">
      <div class="card card--large">
          <div class="card__header">
              <h2 class="card__title">Hi</h2>
              <h3 class="card__author">I'm an author</h3>
          </div>
              
          <div class="card__body">
              <p class="card__copy">I'm the copy</p>
              <img class="card__thumbnail">
          </div>
      </div>
  </div>

Conclusion

Object Oriented principles can help to make your CSS more maintainable. At the end of the day, it’s what works for your team and for your personal taste. I’ve shown you how I like to organize my CSS. I’d love to hear back from you with what’s worked for you and your teams!

Discover more object-oriented principles in our article on mutability and immutability now!

From 11th to the 17th April, save up to 70% on some of our top web development titles. From Angular 2 to Flask, we’re sure you’ll find something to keep you learning… Find them here.

About the author

Liz Tom is a Software Developer at Pop Art, Inc in Portland, OR.  Liz’s passion for full stack development and digital media makes her a natural fit at Pop Art.  When she’s not in the office, you can find Liz attempting parkour and going to check out interactive displays at museums.

LEAVE A REPLY

Please enter your comment!
Please enter your name here