Published

When I was studying in the National University of Singapore our lecturers were eager to raise us not merely as “Programmers” but as Software Architects. Where the Programmer lays bricks, the Software Architect is thinking about higher-level design: where do those walls go in the first place?

In recent years, something similar has been happening with CSS — people started thinking about CSS architecture to ensure that styles were reusable and the website itself could scale. I don’t know who kicked off the discussion but my first exposure to a formalized, higher-level technique of writing CSS was Object Oriented CSS (OOCSS). The name threw many off and I found myself comparing it to the Object Oriented Programming Methodology from my days learning Java.

Object Oriented CSS

In essence, OOCSS identifies webpage elements as objects and abstracts common elements as CSS classes. Following OOCSS conventions, a generic Module would would have the CSS class mod and be marked up as such:

<div class="mod">
        <div class="inner">
                <div class="hd">Block Head</div>
                <div class="bd">Block Body</div>
                <div class="ft">Block Foot</div>
        </div>
</div>

Different classes are then applied to the webpage element, in essence (to use Object Oriented language) extending the object.

<div class="mod grab">
  <b class="top">
    <b class="tl"></b>
    <b class="tr"></b>
  </b>
  <div class="inner">
    <div class="hd">
      <h3>grab</h3>
    </div>
    <div class="bd">
      <p>Body</p>
    </div>
  </div>
  <b class="bottom">
    <b class="bl"></b>
    <b class="br"></b>
  </b>
</div>

Naturally, CSS classes would apply the styles:

.mod {
  /* Styles inherited by all Modules. */
}

.grab {
  /* Styles for Modules of type Grab. */
}

This idea of stacking CSS classes to make an element more “specific” has been embedded since CSS 2.1 with the ability to construct CSS selectors containing multiple classes chained together.

.mod.grab {
  /* Styles for elements which have both mod and grab as class names. */
}

My guess is IE6’s lack of support for multiple class selectors is what stopped people from really using these selectors as a way of building more specific webpage elements. With the browsers we have today though, this is no longer an issue.

BEM: Block, Element, Modifier

Another approach to CSS architecture is BEM which stands for Block, Element and Modifier. BEM starts by identifying the different Blocks on a webpage (e.g. the Header, the Footer etc…). These Blocks can contain other Blocks (e.g. a login module, a search module) or Elements which perform a certain function (e.g. an input field, a button). A Modifier will alter the look or behaviour of that Block or Element (e.g. laying a list out horizontally instead of vertically).

Different Strokes, Different Folks

Both OOCSS and BEM provide a formal language for higher-level CSS architecture. Their approaches are different but there are underlying similarities which have me believe that in all our years of writing CSS we have all been hitting a common set of issues. There is a need for better structured CSS.

And no where was this made more obvious to me than when I started purchasing templates for systems like WordPress and Joomla. Each author had their own system and naming conventions for CSS and many overused IDs which required ridiculous CSS selectors with little semantic weight to over-write.

CSS frameworks are already using this idea of object abstraction & extension. Take a look at the different ways Bootstrap marks up the button element.

<!-- Standard button -->
<button type="button" class="btn btn-default">Default</button>

<!-- Provides extra visual weight and identifies the primary action in a set of buttons -->
<button type="button" class="btn btn-primary">Primary</button>

<!-- Indicates a successful or positive action -->
<button type="button" class="btn btn-success">Success</button>

<!-- Contextual button for informational alert messages -->
<button type="button" class="btn btn-info">Info</button>

<!-- Indicates caution should be taken with this action -->
<button type="button" class="btn btn-warning">Warning</button>

<!-- Indicates a dangerous or potentially negative action -->
<button type="button" class="btn btn-danger">Danger</button>

<!-- Deemphasize a button by making it look like a link while maintaining button behavior -->
<button type="button" class="btn btn-link">Link</button>

This way of writing CSS will (hopefully) trickle down to the “lowly” programmer. But until then I’m going to have to grit my teeth while I build on someone else’s template.