visit our site
Module example

Object Oriented Thinking in CSS: Modules

In Front End

by Dmitry Pliska by November 4, 2013

In one of our previous blog posts, we’ve already described Object Oriented Thinking and objects theory. But what if indivisible objects are not enough to have decent organization and structuring? Assembling application together from the huge set of atomic objects is not so easy. If your app has a quite rich UI and your objects library looks like subway station in morning peak hours — most likely it is time to consider building modules.

Defining a module

Module is a unique composite component that consists of objects. In other words, this is an object made from objects. It’s easier to think of modules from the atomic physics analogy where objects would be atoms and modules – molecules.

Modules necessity

Module usage might seem non-evident and doubtful considering that separation objects and modules appear to be complex and not-so-obvious.
It is much easier, however, to maintain and support objects united by certain principles into something bigger.

Let’s say we have a simple form:

Simple form

Evidently, each of the three elements is an object:

But at the same time we understand that the contact form can be treated as an object itself: it is consistent, simple, independent, and can be reused without any modifications. Therefore, it’d be logical to have it as an object for easy maintenance and re-use. The only difference is that it’s divisible; and this will be the main distinction between modules and objects.

Modules modifiers

Modifying modules follows the same logic as modifying objects. If you need to modify a module, do it with the modificator class name.

For example, below is a variation of the form we’re already familiar with:

Modified form

It’s easy to see that structure is the same and appearance makes the only difference. So, we add a modificator class:

and corresponding style rules which will add appearance guides or override the default ones:

Please note there is a specific aspect here: it may be hard to outline a modification target – module or object.
If you see that a requested change is definitely related to the whole module, then this module is what should be extended with modification. But it’s easy to miss the fact that it’s objects that should be modified instead of the whole module.

Back to our example, we have two variations of inputs: grey-backgrounded and white-backgrounded.

So, most likely, there are two possible scenarios:

  1. The only place where different inputs are present is two contact forms.
    These are the circumstances for module modification, exactly like described above.

  2. Or, on the contrary, they can be found throughout the whole app within many cases.
    In this case we should modify object(s) itself, not the whole module (form):

Module selectors nesting

Coding modules should not make you write much more complicated code that simple objects do. This means that depth of selectors nesting should not reach more that ~3-4 levels deep.
Getting deeper than that may result into one or more of following:

Overcomplicating a module

It’s a common case when module continues to grow iteratively and it’s hard to pick the moment when it grows out from the cradle. But keep an eye on it. Unwatched module can become a trouble-making monstrosity. Just consider to break the module into a few smaller ones.

Modifying a module instead of creating new objects

The case that we’ve described in the forms example above. What should I modify: module or objects? Module stylesheet size and complexity can be a hint here.

Redundant helper wrappers

The case where you put some wrappers and they migrated to css selectors making them inexplicably long. Note that css rules should include only structural dependencies.
I.e., you have a section with inner div and object inside it:

And rules for the button should be declared like this:

Instead of:

Moreover, you can consider removing non-structural wrappers and moving their appearance to :before or :after pseudoclasses. This approach will make your structure clearer and should help eliminate the problem with selectors chain described above.


Modules are just an extended OOCSS approach which helps to keep code structured and well-organized. Most of its benefits are felt on large products where simple objects can be combined together in modules. In this case, modules can really help you keep your code easily extendable and scalable.

* Railsware is a premium software development consulting company, focused on delivering great web and mobile applications. Learn more about us.
  • Vladimir Melnick (

    I don’t think that using different styles in classes with the same name is a good practice. I mean this:

    input[type=text].muted {
    background-color: #ebebeb;

    input[type=submit].muted {
    background-color: #262626;

    input[type=submit].muted {
    background-color: #262626;

    And modules are not what you said. Module is a something independent and embeddable. Modules in CSS maybe should be similar to:

    #module .some-class { … }
    #module .another-class { … }

    But it looks like we do not embed modules into objects, but embed objects into modules (namespaces with special rules). And this is wrong solution because it is complicated and has performance issues (not big problems, but why we should have deal with them?). CSS has no real modules. SCSS has them. They called “mixins” and we can embed some CSS code to some classes or ids or any other selectors and than comile it to plain CSS. We will duplicate code in CSS but not in SCSS with which we work.

    P.S. Sorry for my English.

    • Dmitry Pliska

      Thnx for your comment.

      First, in this example same name shows logic affiliation for text box (input[type=text]) and button (input[type=submit]). I doubt that text box and button should have exactly the same colors for muted or disabled state :)

      Second, I don’t say that my vision of modules are the one and only. Its a vision front-end developers use in Railsware and, of course, there can be many more, even with diametrically opposite approaches. And its totally fine with me.

      Your analogy between modules and SASS mixins is understandable but mixin is just a tool and module is an approach, way of thinking. So I would say that nor CSS neither SASS has modules or objects :) Tools can be used whatever way, based on approach. And approach is exactly what I’ve tried to describe in post above.

      Feel free to bring more arguments :)

      • Vladimir Melnick (

        I’m not a front-end developer, so you know better, but as for me using OO paradigm for CSS is not a good approach. And this is the main idea of my message.

        • Dmitry Pliska

          I appreciate your input.
          We don’t say our way is best one. We just sharing our vision hoping it can help :)

Signup for our weekly newsletter

Want to get more of Railsware blog?

RSS Feed

We're always ready to help!

Contact us