visit our site

Object Oriented Thinking in CSS

In Front End

by Alex Chaplinsky by October 22, 2013

Most modern methodologies like OOCSS, BEM, SMACSS are all about learning to think about your UI and CSS in terms of objects. Which appeared to be really useful and flexible approach to organize and reuse code-base leaving it simple and DRY.

Objects are simple independent and indivisible components that are used across the project. We can think of them as interface elements like headings, form fields, buttons and content blocks.

Here is a simplest example of a button object:

Everything looks simple so far but apparently this is not the only type of buttons you’ll need during the project. You may need buttons of different size, colors and behaviour and here is where you have several options.


Let’s think about .button as about parent class in programming languages, we’ll be extending with child classes. It’s useful for inheriting the properties of parent object while adding additional behavior. Let’s say we want to create two more simple types of buttons – button with icon before text and dropdown button.

Now we are able to create both child elements by applying parent and child class to button element.


Not to create a mess in HTML and reduce number of classes applied to the element one more optimization is required. We can list our child classes with coma right after parent class in selector, so that all these classes will have common styles and two of them will differ in a minor way.

In this case you can use only one of .button, .iconed-button, .dropdown-button classes in your HTML applying it to the button element.




Modifier classes are used to make minor modifications to the existing behavior or to indicate that the object is in a certain state. Nouns are used for object’s class names, in case of classes modifiers it is apparent to use adjectives.

Modifiers are meant to modify which means to override some properties of ‘default’ objects whereas subclassing is used to extend them with new properties, thus creating new objects.

This is how by applying a .primary or .disabled modifier to the button object we can now change the coloring of button. In this case, we also wanted to force these modifiers to apply to the button object only so we used .button class in selector.

Parental namespacing

One more way to change object’s appearance or behaviour is to use parent’s class name in selector to add changes to the object. Location dependent styles are usually the kind of things you should avoid, because in general object’s styles should not depend on placement. But in rare cases you may come up with an idea of modifying object due to it’s location. For example let’s make the submit button larger than the default one.

In this case the button will remain an independent object you can place anywhere on the page, and only if placed inside signup form it will change its appearance.


Despite the fact that CSS, unlike programming languages, is declarative, there’s a lot to pick from object oriented programming. Thinking “objects” is the kind of skill that will help you create re-usable objects and stop writing redundant code. It becomes easy to maintain code base and make modifications to existing UI without harming different parts of application.

* Railsware is a premium software development consulting company, focused on delivering great web and mobile applications. Learn more about us.
  • Pingback: Object Oriented Thinking in CSS: Modules | Railsware Blog()

  • Vladimir Melnick (

    Firstly, this is not an OOP. This similar to mixins in Ruby or traits in Scala.

    Secondly, CSS isn’t a programming language and OO-paradigm is not silver bullet, so we should not use it anywhere. Thirdly, here you break Single Responsibility Principle when you define styles for: decoration, positioning, size and typography in the same class. Fourthly, you broke Open/Closed Principle when you said about modifiers. And also you will have problems with that you broke incapsulation of class here:

    .signup-form .button {
    padding: 8px 20px;

    I think that parent elements should have only ability to define positioning of childrens and not to change his children.

    P.S. Sorry for my English.

    • Alexander Chaplinsky

      Thanks for a feedback.

      If you’ve read post attentively, you must agree nobody says “Let’s use OOP paradigm in CSS!”:) Of course CSS isn’t a programming language, otherwise we wouldn’t need materials about how to write css. A book about OOP would be enough)

      But post is about thinking objects. Not ruby objects, but Interface objects, because each interface consist of different elements and it’s modifications. And we need an appropriate way to organize styles and stay modular and flexible.

      Good point about Single Responsibility Principle! That’s a topic that should be highlighted in a separate blog post i think. But let’s keep in mind that examples above – are just simple enough examples. And the main point was to describe building and combining selectors, but not CSS rules:)

Signup for our weekly newsletter

Want to get more of Railsware blog?

RSS Feed

We're always ready to help!

Contact us