Front End CSS Design Paradigms have been a very hot topic lately and many people are attempting to solve the problem of large CSS rule sets that are difficult to maintain. With all the new options it might be difficult to decide where you should focus your attention. Here is a little overview of some of the more popular options.

Object Oriented CSS

OOCSS has several principles that it is built upon.

1. A style should be written once and only once.
2. Separate Structure from Skin (or layout from style)
3. Separate Content from Containers

A Style should be written once and only once

If you are declaring the same exact style rules over and over again then you are probably doing something wrong.
Take a look at this example.

#thumbnail {
  width: 200px;
  height: 50px;
  padding: 10px;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}


block {

width: 400px;
  overflow: hidden;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

view {

width: 500px;
  min-height: 200px;
  overflow: auto;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

All of these above styles are unique; however, they are also repeating the same rules over and over again. These styles can be simplified if a class is added that absorbs these repeated rules. This class would then be applied to the html elements.

.thumbnail {
  width: 200px;
  height: 50px;
}


.block {
  width: 400px;
  overflow: hidden;
}

.view {
  width: 500px;
  min-height: 200px;
  overflow: auto;
}

.box {
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

This is much simpler with far fewer lines and if the global style changes the change only needs to be made once.

Separate Structure from Skin

In OOCSS the Structure is generally non-repeated style that works toward organization. This is what puts a sidebar on the left and the content in the middle. The concept of the Skin are the branding or theme of the site. Fonts, Colors, Gradients, Borders, and Rounder Corners are all apart of the skin.

Separate Content from Containers

All this means is that the style should not depend on a complex (or simple) html structure. Instead of writing a rule like this:

#sidebar-first h2, #content h2, #header h1 {
  ...
}

Instead apply a new class to the h2 in the header, content area, and first sidebar. That way the repeated rule can be applied to that single class and then on those specific CSS elements we can overwrite the rule. In other words let the rules cascade and then overwrite them the way CSS was designed.

What OOCSS doesn't want you to do

• DO NOT use descendant selectors
• DO NOT use ID for styling elements
• DO NOT use class attachment for CSS selectors
• Avoid unless absolutely messes the use of !important

The Down side to OOCSS

This doesn't easily apply to Drupal very well. This is a good concept, and should be reviewed as a good way to keep CSS organized. However, unless a site is requiring an extreme amount of front end work (to the point of completely custom html --where the default Drupal output just will not work) then this system is nearly unusable because it requires additional classes to be written to the html in order to accomplish this.

SMACSS Scalable and Modular Architecture for CSS

There are far more rules for SMACSS than I can put into this article. Here is the simple orbital overview: Just like with OOCSS we are encouraged to put everything into classes and distribute those classes out to the html as needed. The big differences are that SMACSS knows that there are times when using descendant selectors and IDs are messes. Therefore SMACSS gives us guidelines for using them. Isn't that nice!

There are five categories that components will fall into when writing SMACSS: Base, Layout, Module, State, and Theme.

Each of these rules has a coding standard and class prefix. That is beyond the scope of this article --I suggest reading the SMACSS website for detailed information.

The guide for each of these categories are as follows:

• Base - Normalization or style resetting
• Layout - Positional Styling of structural elements on the page
• Module - Modules are meant to be standalone stylistic elements. These are the parts that will be defined by classes and applied where messes to the html.
• State - Hover, Active and other state aware styles. If the style is dependent upon JavaScript then it is in the State category.
• Theme - This is the unique, non-repeated overrides of the style. The generic stuff gets put into Modules and then the Theme overrides where messes.

The Downside to SMACSS

SMACSS is extremely strict. There are rules for everything. When implementing SMACSS you really need to know what you are doing or you could end up spending all your time worrying about implementing SMACSS and not writing good CSS.

Block Element Modifier

In practice BEM is a simplified combination of OOCSS and SMACSS. Unlike the other two BEM stresses for quick development over style structure. In BEM there are three types of component: a block, an element and a modifier.

• Blocks are the largest independent container; Header, Footer, and Content would all be considered blocks.
• Elements are the independent components inside the block.
• Modifiers are added to both blocks and elements to allow for both style reuse and visually uniqueness.

BEM offers a way to think about CSS and front-end development and just like OOCSS and SMACSS it offers a strict set of guidelines around it. So strict that they offer tools that that will lay it all out for you and enforce the BEM naming conventions and html structure.

The Downside to BEM

BEM is an ideal solution and it seems to know it. The BEM Methodology page is shorter than this article.On the surface, BEM is a simple methodology; however, that simplicity goes away very quickly. Once you get past the philosophical methodology page and into the actual guidelines it becomes clear that the guidelines are far more strict. This strictness rules over the html structure and the CSS. If you are comfortable working the html and class names that a CMS will give you then you should feel right at home with BEM.

DRY Don't Repeat Yourself

Keeping with the spirit of DRY I will not go into great detail about it. The reason is that it follows nearly the exact same principles as the above SMACSS and OOCSS. The only difference is that ID selectors are fine and naming convention should be based on content.

Who Wins?

SMACSS.

At least for Drupal SMACSS won. What does this mean for Drupal development today? I will write another article explaining how to apply SMACSS to Drupal 7 Development soon.