I’d love to dive right in and show you how it all works in cujo.js, but you’ve got to have a firm understanding of OOCSS for any of it to make sense. Let’s get started…

Basic principles of OOCSS

Where better to learn the basic principles of Nicole Sullivan’s OOCSS than from the source? I highly recommend you watch the slideshow and read the FAQ. Here are some of the main points:

An “object” in OOCSS is an HTML fragment and its associated CSS classes*.
You extend objects by applying multiple classes to its root element.
You must follow some basic guidelines:
Separate structure from skin (styling).
Separate container from content.
Don’t use ID attributes to define CSS rules.
Use CSS “hacks” for targeting and fixing browser quirks.

*Nicole alludes to some JavaScript associated with these OOCSS “objects” (a hilariously surprising assessment from the perspective of a JavaScript engineer who might think of JavaScript as the primary language and of CSS as secondary).

Nicole includes several other guidelines, as well. All the guidelines can be summarized into three major categories: 1) guidelines to help reuse objects and CSS classes, 2) guidelines to prevent unnecessary specificity increases, and 3) guidelines to allow OOCSS principles to work in ancient browsers.

The ultimate benefit of following OOCSS principles is optimal reuse of CSS rules and OOCSS objects.

For an excellent and detailed example of OOCSS in action (and a very slick use of CSS3), jump over to Brian Cavalier’s blog post, Building a digital clock with OOCSS and MVC and come back.

OOCSS inheritance

If code reuse were the end of the story about OOCSS, it would certainly be no small achievement, to say the least. Nicole has done an amazing service to the web industry, especially to those whose main job is to wrangle CSS. But little did she know, she also planted a seed of inspiration in several JavaScript engineers’ heads, mine included. I had been already trying to form solid ideas around very similar CSS patterns, but couldn’t find the right words or evidence. After watching her speak live at TXJS 2010, things started to become crystal clear — especially when she started talking about reusable objects.

One of the most common methods to reuse code is through inheritance. In classical object-oriented languages, classes inherit attributes and behavior from ancestor classes. The classes are then used to construct objects. In prototypal languages (such as JavaScript), objects inherit attributes and behavior from ancestor objects. However, in OOCSS, objects inherit attributes and run-time state from ancestor objects.

Read that one more time: “…objects inherit attributes and run-time state…” We’re not talking about some static, compile-time concept as with classical inheritance. And we’re not talking about inheritance that happens during object construction. We’re talking about run-time, baby!

As an object changes at run time from one state to another, so too do it’s descendants. Or, conversely, as an object’s ancestors states change, so too does the object. Brian and I talked about this concept and dubbed the term, “whole state”, to describe the object’s current state combined with the states of its ancestors.

Let’s jump right into an example to better grasp this. Here’s a simple HTML snippet from a facetious “club” project:

<section class="club-view club-hawt-view">
    <ul class="club-list">
        <li class="club-item club-rock-item">1st Item</li>
        <li class="club-item club-disco-item">2nd Item</li>
        <li class="club-item club-pop-item">3rd Item</li>
    </ul>
    <button class="dance-mode-selector">Let's do Disco!</button>
</section>

Notice the name-spaced css classes (using dash-notation to be friendly to HTML4 strict documents). While not important to this discussion, name-spaces are important to protect your code from name conflicts in large projects, especially if not all of the CSS uses OOCSS principles!

More importantly, notice the classes on the root element of our topmost “object”. club-view and club-hawt-view describe static classes in the classical or prototypal sense. club-hawt-view is a specialization of club-view. Underneath this club-view object (as we’ll call it for simplicity’s sake), we have other objects: club-list and club-item. club-item has three different specializations, as well: club-rock-item, club-disco-item, and club-pop-item.

Note that we must specify both the base (ancestor) and specialization (descendant) classes on the element. This is because CSS does not specify a way to declare the inheritance relationship in the stylesheet. This is not a limitation of CSS, in my opinion, just an implementation detail.

Interestingly, Nicole calls for declarative inheritance in her slides. This would allow the designer to specify the link to the ancestor class in the stylesheet, rather than in the HTML. Thus, only club-hawt-view would need to be specified on the object since the stylesheet would declare the link to the ancestor, club-view.

(Some other projects have implemented compile-time solutions to provide declarative inheritance. However, declarative inheritance in the stylesheet may do little except save some bulk in the HTML, imho. I’m on the fence about it. It feels like it’s an idea invented out of basic misunderstanding of CSS inheritance, but I can’t really see any significant down-sides at the moment, either. In fact, if used correctly, it may help clarify the difference between specialization CSS classes and stateful CSS classes in the HTML.)

OOCSS state

Now, imagine that we want to place our club-view object into disco mode when the user clicks the button. In disco mode, we want to highlight certain objects and de-emphasize — or even hide — others. For instance, we don’t want to show any club-rock-item objects. (Cuz rockers don’t do disco.) We could set them to display:none, in this case.

In a noobish implementation of this behavior, we would simply catch the button’s click event, query the club-rock-item elements, and hide them. This is seductively easy (and dangerous) in jQuery:

$('.dance-mode-selector').click(function () {
    $('.club-rock-item').css('display', 'none');
});

or dojo:

dojo.query('.dance-mode-selector').onclick(function () {
    dojo.query('.club-rock-item').style('display', 'none');
});

The less noobish of us know it’s a lot more cpu-efficient and flexible if we did this using CSS classes instead of manipulating the nodes’ styles directly. Let’s add the following CSS rule and change the click event handler to use it:

.club-disco-mode .club-rock-item { display: none; }

dojo.query('.dance-mode-selector').onclick(function () {
    dojo.query('.club-view').addClass('club-disco-mode');
});

The resulting HTML would look like this:

<section class="club-view club-hawt-view club-disco-mode">
    <ul class="club-list">
        <li class="club-item club-rock-item">1st Item</li>
        <li class="club-item club-disco-item">2nd Item</li>
        <li class="club-item club-pop-item">3rd Item</li>
    </ul>
    <button class="dance-mode-selector">Let's do Disco!</button>
</section>

Notice I put the club-disco-mode class on the root object, not the club-rock-item objects (more about this in the next section). Changing the CSS class instead of direct DOM styling puts the task of deciding how to handle club-disco-mode in the hands of the CSS designer where it belongs. For instance, once she’s seen the button jolt upwards (as it would when the club-rock-item object disappeared), she’d likely throw up a little in her mouth or have a mild seizure induced by this severe UX faux pas! Then she might mute the colors instead of removing the element from the layout.

The beauty of this is that there’s no need to mess with the JavaScript to make this change. The task of deciding styling and layout for this state change is defined entirely in the CSS. In fact, the only dependency between the CSS and the JavaScript is the coordination of a single class name, club-disco-mode, on the root element of our object. You can think of this class name as a message from the JavaScript to the CSS, telling the OOCSS object that it is in a new state. We’ve essentially just decoupled the JavaScript from the CSS using a classic method used in object-oriented programming: message passing.

Not impressed so far? This is just good CSS practices cast in the light of classical OO, you say? Ha ha, don’t worry. We’ve only scratched the surface. In a subsequent blog post, I’ll show you how cujo.js abstracts the concept of state changes, allowing both CSS (style and layout) and JavaScript (behavioral) state changes to execute in parallel with a single line of code.

But first, let’s dig a little deeper into run-time state inheritance…

OOCSS run-time state inheritance

In our “club” app, we can also treat the repeated club-item elements as objects, too. When we change the state of the root club-view object to club-disco-mode, we’ve also changed the state of all of the club-item objects. We can take advantage of this by declaring OOCSS rules like the one below. This rule is just like the earlier rule, but the style declarations have been changed to something less seizure-inducing to somebody with UX sensitivities:

.club-disco-mode .club-rock-item { background-color: #ccc; color: #777; } /* grayed-out */

You could read this as club-rock-item objects under the state of club-disco-mode. If we wanted to be even more explicit, we could write it like this:

.club-view.club-disco-mode .club-rock-item { background-color: #ccc; color: #777; } /* grayed-out */

This translates to club-rock-item objects under club-view objects in the club-disco-mode state. Here we see how the club-rock-item objects inherit the state of their ancestor(s) and how we can define the style attributes of those objects in response to that state. In the more explicit variant, we’ve also increased the specificity, which may not be desirable in all situations, so the shorter variant is also acceptable as long as it can’t be interpreted ambiguously.

So, why did I declare the rules this way? Why didn’t I change the state on the club-rock-item objects instead of the club-view object? Because the button’s stated purpose is to change the state of the entire object, not of only the club-item objects! Too often, we JavaScript engineers concentrate too much on the task at hand (manipulating the club-rock-item elements), not the semantic meaning of the user’s action (to change the state of the club-view object).

Let’s revisit the club-hawt-view specialization class to better illustrate an example of why this is so important. When this class is applied to our object, we potentially inherit a whole new set of CSS rules. One of these rules could define an entirely different layout or a different styling. Maybe in a club-hawt-view we’ve turned up the heat a bit:

.club-hawt-view { background-color: #fa7; color: #500; } /* red on orange! HAWT! */

It just wouldn’t fit to de-emphasized the club-rock-item objects with a gray background, anymore. The gray and orange clash. Instead, when we’re in the club-disco-mode state, let’s embolden the font on the emphasized objects and just change the font color on the de-emphasized club-rock-item, not the background. Let’s also add a dotted border around the whole object (yah, yah, I know this is getting really damn ugly, but hey, I’m an engineer):

.club-hawt-view.club-disco-mode .club-disco-item,
.club-hawt-view.club-disco-mode .club-pop-item { 
    font-weight: bold; 
} 
.club-hawt-view.club-disco-mode .club-rock-item { background-color: transparent; color: #777; } 
.club-hawt-view.club-disco-mode { border: 1px dotted pink; }

The key point is that we didn’t have to change the JavaScript to deal with the specialized, club-hawt-view object. We still just passed the same club-disco-mode message to the OOCSS club-view object from the JavaScript in response to a button click:

dojo.query('.dance-mode-selector').onclick(function () {
    dojo.query('.club-view').addClass('club-disco-mode'); // still the same exact code!
});

OOCSS decreases risk

This has been a simple example, but you can start to imagine why using JavaScript to programmatically change styling starts to get ugly. Here’s what the code might look like if we used JavaScript instead of CSS:

dojo.query('.dance-mode-selector').onclick(function () {
    dojo.query('.club-item').forEach(function (item) {
        if (dojo.hasClass(item, 'club-disco-item') || dojo.hasClass(item, 'club-pop-item')) {
            dojo.style(item, 'fontWeight', 'bold');
        }
        else {
            dojo.style(item, { backgroundColor: 'transparent', color: '#777' });
        }
    });
    dojo.style(this, 'border', '1px dotted pink');
});

This is not reusable code, nor is it very maintainable once you start getting into more complex, real-life projects. Brian pointed out to me that the general complexity of the situation can be summarized as O(n^m), where n == the total number of CSS classes on a node and m is the number of ancestry levels we may need to manipulate. If we’re handling just 3 CSS classes on 3 levels, we’ve got up to 27 separate cases to consider in code.

Worst of all, we’ve inextricably tied our button and our club-item elements together. If we were to suddenly need a variation of the club-view objects without the club-item objects at all, we’d be forced to branch yet again.

As Brian said in his post, declarative code — such as CSS — is inherently less risky to modify than procedural code.

OOCSS in ancient browsers

The astute CSS developer will have identified several problems with all of the CSS I’ve shown. Specifically, none of it will work in IE6 at all! Combination class selectors (.club-hawt-view.club-disco-mode, for instance) and transparency weren’t supported in IE until version 7. Not to worry, cujo.js fixes those automatically. It also fixes several other CSS2.1 and CSS3 shortcomings in IE. cujo.js doesn’t come close to bringing IE up to CSS3 specifications, though, so don’t get too excited. cujo.js only fixes IE enough to allow OOCSS to work to its fullest potential while also removing the dependencies between CSS, HTML, and JavaScript. Separation of concerns has always been a major goal of CSS, but only CSS3 finally fulfills it. More on that in yet another future blog post.

[update]
For years I thought IE6 didn’t support combination class selectors! People are telling me that they work as long as you order the classes correctly (.bar.foo {} versus .foo.bar {}). I must always order them the way that doesn’t work. I’ll do some further testing and verify.
[/update]

You likely also noticed that Brian is using CSS3 transitions in his project. Transitions are a critically powerful tool in any UX designers toolkit. Unfortunately, IE and Firefox still don’t support transitions (as of September 2010). No biggie, cujo.js fixes that, too. We’ve even extended transitions to include more popular timing functions such as bounce, elastic, sine, etc. We’re also investigating other, more advanced types of transitions to emulate common use cases that don’t fit the CSS3 transitions model at all.

For instance, transitions alone can’t animate an element being tossed into the trash. Too often the element being deleted and the trash icon don’t share the same offsetParent or there’s an ancestor with overflow:hidden somewhere between. For situations like this, you’d typically have to append the node to some common ancestor (likely the body element) and then animate it from the original location to the trash icon. That kind of sequence comes in handy for accessibility-friendly alternatives to drag-and-drop — as well as a few other use cases. So, we’ll be investigating ways to allow the CSS designer to take control of complex transitions like these without tinkering with the engineer’s JavaScript.

Still not convinced of the benefits of OOCSS? Next we’ll see how to apply it in a client-side MVC architecture. OOCSS becomes even more powerful when you combine it with view-controllers based on OOJS and ultra-simple, inheritable templates I’ve dubbed OOHTML.

What do you think so far? Does OOCSS make sense? Have you already used it in an MVC-based environment? Let me know!

In my previous post, I laid out the basic Javascript inheritance mechanism, prototype chaining. In this post, I’ll elaborate on it a bit more by showing how I took this basic concept and created something workable for some very bright, but prototype-phobic programmers: Oracle Life Sciences division’s Java developers! (Java and Javascript couldn’t be more different in almost every regard, especially concerning inheritance.)

Even though I had been using Javascript quite heavily since 1996, I was clueless to its object-oriented capabilities until 2004. That’s when I discovered prototype.js, one of the first Javascript frameworks — and still one of the best, imho. One of the reasons I love prototype.js is because it extends the native Javascript objects, rather than wraps them. (This, also, btw, is one of the aspects of prototype.js that people don’t like.) But to me, it just feels so much more powerful, natural, and expressive. This is the way that Javascript was meant to be used!

Well, that said, I plan to talk about how I gleaned some knowledge from an exception to prototoype.js’s extend-rather-than-wrap rule in version 1.3. The Class.create() method breaks from prototype.js’s usual m.o. and hides the native, natural prototypal inheritance of Javascript with a more classical-looking inheritance mechanism (e.g. more Java-like). At first, I hated that prototype.js did this — but so did every other major framework.

However, I warmed up to it when I was tasked to create a new Javascript framework from scratch at Oracle. The reason for my change-of-heart is simple: wrapping the inheritance mechanism creates an opportunity to do magical things and reduces the overall code size at the same time.

Primer / reminder: prototypal inheritance uses slightly different concepts from classical OO:

• constructor <==> class
• prototype members <==> class members

OK. Time for some code. Our wrapper function looked a lot like this:

Object.Extend = function (/* Function|Object */ base, /* Function */ construct) {
  var baseIsObj = typeof base == 'object';
  construct.prototype = baseIsObj ? base : new base();
  construct.prototype.superclass = baseIsObj ? base.constructor.prototype : base.prototype;
  return construct;
}

In summary, Object.Extend takes a base constructor function or prototype object (base) and a new constructor function (construct). As you would expect, it chains the prototype of the new constructor function to the base constructor function, which allows the objects created with the new constructor to inherit members from the old constructor. Nothing new here.

var MySubClass = Object.Extend(MyBaseClass, function () { /* do stuff here */ });

If an object is passed instead of the base constructor, it is used directly as the prototype. Typically, the developer would pass the prototype from an existing base constructor or an object literal to serve as a prototype. However, as an interesting twist, the developer could choose to pass an instantiated object from a previously-defined constructor. This can provide some very interesting object hierarchies, but likely with unintentional consequences. (This might be a good topic for a later blog post.)

More importantly, our wrapper method gave us the opportunity for some syntactic sugar. We’ve added a new property to our new constructor’s prototype: superclass. This property allows us to access our object’s immediate ancestor prototype directly. By default, Javascript forces the developer to know the ancestor prototype in advance, which can be problematic or simply impossible in polymorphic situations.

Default Javascript method to access an ancestor prototype:

MyClass.prototype.someMethod = function () {
    AncestorClass.prototype.someMethod.apply(this, arguments);
    /* do other stuff here */
};

Our new method to access our immediate ancestor’s prototype:

MyClass.prototype.someMethod = function () {
    this.superclass.someMethod(arguments);
    /* do other stuff here */
};

Besides being more compact, our new method prevents us from having to know our immediate ancestor! R0x0r!

Wait a minute, I seem to remember that this isn’t really a freebie. I remember several issues that appeared when the ancestor’s implementation of someMethod called upon other methods or properties. The superclass property had to be used very carefully or it would result in unpredictable results or infinite loops (ugh, I think I need another blog post for this). In the Oracle framework, we used the superclass property very sparingly.

Another side-effect of our Object.Event wrapper is that we must allow our base constructor function to be able to take zero parameters. This was initially a show-stopper for me. I’d been so accustomed to passing initialization parameters to my classes in classical OO. It’s good programming practice to force developers to pass parameters that are necessary for proper object instantiation. At Oracle, we got used to calling an init() method on our objects immediately after instantiating them, passing any necessary parameters to this method.

This zero parameters problem is easily worked around for the general case by providing an instantiation method in the constructor’s prototype. This is precisely the way that prototype.js and some other frameworks do it. A call to

this.initialize.apply(this, arguments);

occurs in the wrapper function.

It’s very interesting to note that prototype.jsalso implements a second-level of prototypal inheritance within it’s wrapper. It constructs an inner object and places it into the prototype chain. This solves some of the problems we had at Oracle and also handily solves the problems with the superclass property.

Wow. There is so much to talk about! I think I’ll take each of the major frameworks, prototype.js, jQuery, and dojo, and dissect their inheritance wrapper functions. What better way to understand the intricacies of object-oriented Javascript!

This article assumes that you, the reader, have a background in object-oriented programming techniques. If not, please check out the primer at Wikipedia.

Javascript is a prototypal language. This means that objects inherit from other objects and that object classes describe their common behavior via prototypes. Prototypes are akin to member declarations in classical inheritance. For example, if a Javascript object, A, has a method, doSomething(), in its prototype, then another object of the same “class”, say object B, also has a method, doSomething(), in its prototype. (Notice I quoted the word, “class”. More on that below.)

If objects A and B inherit from another object, C, then they both inherit any members on C’s prototype. This is because the prototypes are “chained”. At run-time, when a member is referenced on an object, the prototype chain is scanned. For example, if C has a method, doSomethingElse(), then calling A.doSomethingElse() is valid.

Like some other languages, Javascript uses the familiar new operator. However, surprisingly, there is no formal method to declare a class. Instead of using it on a class, the new operator is used on a function. (In fact, it can be used on any function!) The new operator simply interprets the function as an object constructor and pulls the function’s prototype into the new object’s prototype chain.

A prototype chain is similar in nature to a classical inheritance heirarchy. Here is a simple example:

var Pet = function () { };
// using object literal (shorthand) notation:
Pet.prototype = {
  eat: function () { /* do something here */ },
  sleep: function () { /* do something here */ },
  play: function () { /* do something here */ }
};
 
var Cat = function () { };
Cat.prototype = new Pet(); // chain prototype
Cat.prototype.technicalName = 'feline';
Cat.prototype.scratch = function () { /* do something here */ };
Cat.prototype.meow = function () { return 20; /* decibels */ };
 
var SiameseCat = function () { };
SiameseCat.prototype = new Cat(); // chain prototype
SiameseCat.prototype.breedName = 'Siamese';
SiameseCat.prototype.meow = function () {
  // call ancestor method
  return Cat.prototype.meow.call(this) * 3;
};
 
var myCat = new SiameseCat();
myCat.play(); // inherited from Pet
myCat.scratch(); // inherited from Cat
myCat.meow(); // from SiameseCat

However, since Javascript is so flexible, it lends itself to several variations and alternatives. This is where the fun begins…