I’ve been thinking a lot about OOCSS and MVC-in-the-browser over the past months. These certainly aren’t things I invented, but what I found is that my own philosophy of building applications for the web had evolved to include these concepts. It was only later that I learned that some really smart folks had also been thinking about these things, and had given them names.
So, I created this digital clock app as a simple example of some of the concepts I have been applying to build apps with OOCSS and MVC.
Very shortly after that, I got a walkthrough of John (unscriptable) Hann’s ambitious cujo.js project, and I was blown away by two things. First, he and I had basically come to believe many of the same things about applying OOCSS and MVC, and second, he had actually wrapped those things up in an incredibly simple and intuitive API inside cujo.js.
Let’s get down to business, and look at a few of these techniques in practice. I’ll hope that some theory will fall out of it as I write.
“Is A” and Specialization
Here’s a bit of HTML from the clock.
Some of the classes here set up “is a” relationships. Even though the order of classes in HTML doesn’t matter, I’ve arranged them left to right from general to specific, because I think that makes the most sense. The node “is a” slot—an admittedly awful name for an area in which the clock will display something. Also, it “is a” digit, which in this case, is a specialization of slot that will display a digit.
Farther down, there is another specialization of digit:
This node is still a digit, but more specifically, it’s a second, as opposed to a minute or hour. Looking at the rendered clock, you can see that seconds are smaller than minutes and hours—the presentation of seconds has been specialized to be smaller.
States, Views, and View Controllers
The classes d0 – d9 represent the possible states that the digit may be in. By changing the class, the View Controller is telling the View to change state. The View still “is a” digit, but it has changed state, for example, from a zero to a one. I guess you could say it “was a” zero and now it “is a” one, and that it’s actually mutating to another specialization rather than changing state. I think that’s a reasonable way to think about it—it’s just not how my brain works, so for me, it’s state.
The digits and the state transitions manifest themselves in the browser with the help of CSS. Here’s a bit of the CSS.
This CSS describes what a digit looks like when it’s in state d0 and d1. In addition to describing the resulting state’s presentation, it is also describing the state transition itself—that is, how (in the visual sense) the digit moves from one state to another using CSS3 transitions.
Specializations, State, and Ancestry
One thing that is subtle, but I feel is extremely important here, is that by changing the state of the digit, the state of the elements within the digit (i.e. the glowing bars) is being affected. There are no direct state changes to the bars, yet they are changing. The current state of each bar is defined by the hierarchy of classes above it in the DOM plus its own classes. Or, to put it in more general terms:
The current “whole state” (borrowing a term from a recent conversation with John) of a particular View is defined by the specializations and state of its ancestors plus its own specializations and state.
dojo.style, is not a good engineering practice in another post, but, the key here is that by simply issuing a state transition on an enclosing View, state changes can be affected on its sub-Views.
Let’s look at why that’s interesting and useful on a practical level.
Back to Practical
Imagine you wanted to change the look of the digits by giving the bars beveled ends as some digital displays have, or you wanted to make the entire clock larger or small, or size it using percentages instead of pixels, or introducing a radical new presentation and color theme. You would not need to touch the View Controller. There are several reasons that is a good thing, IMHO, two of which are:
- The changes could be made by the team’s CSS designer, without involving a JS engineer, and
- Changing procedural code, like JS, is typically more risky than changing declarative code, like CSS.
I didn’t need to make any changes to the CSS or HTML. Engineers can craft the JS, and the designers can craft the CSS. Sure, you might play both roles, but that’s not the case with every team, especially in large, complex apps, with many Views, company wide design standards, branding, and a small army of awesome designers complimented by an equally awesome army of software engineers.
I am very excited about building apps using these techniques, and I am especially excited after seeing John’s work so far on cujo.js. If it turns out to embody these concepts like I think it will, it’s gonna be a very powerful platform. I’ll certainly be keeping an eye on it.