unscriptable.com » CSS

OOCSS for JavaScript Pirates

admin — Tue, 16 Nov 2010 03:17:52 +0000

A few weeks back I had the awesome opportunity to speak at the jQuery Conference in Boston. A colleague, Boaz Sender, encouraged me to propose a topic, but I couldn’t help wondering, “What could a dojo enthusiast possibly speak about at a jQuery conference?”

Speak about dojo? Uh, no way. That wouldn’t fly.

How about something about pure JavaScript? Maybe I could extract a feature of cujo.js and turn it into a jQuery plugin! … Nah, that’ll take too long. No time.

Wait! OOCSS! It’s applicable to all JavaScript development!

OOCSS for JavaScript Pirates jQcon Boston

View more presentations from John Hann.

I knew that topic was the best chance I had — if a dojo guy had a chance at all — to speak at a jQuery conference. But how to sell the idea to jQuery developers? Most of the JavaScript coders I know either don’t understand CSS or don’t care to understand it. Well, to be fair, that description fits most of the dojo coders I know. Lots of jQuery devs come from a design background, so they know CSS. But still… how to let the conference attendees know that this talk won’t simply be about the same old CSS concepts?

I’ll have to just tell them it’s for advanced coders! This is CSS for JavaScript Pirates!!!

There were only a few days left before I had to submit the proposal for the talk, so I did what every over-worked coder does: I waited until the night the proposal was due.

I did two revisions before calling it good enough. (I usually like to wait a few days between revisions because it makes it easier for me to judge the content objectively, but that almost never happens.)

At the bottom of my proposal, I added some additional notes:

Note to reviewer: It’s no secret that I’m a dojo contributor working on a dojo-based MVC framework (cujo.js). Let it be known that I’ve also worked on my share of jQuery projects! (Who hasn’t?) This talk is about OOCSS and JavaScript, not cujo.js or dojo. I will be showing jQuery code snippets and will explain techniques that jQuery devs can use in their current projects.

That oughta alleviate any doubters. I hope.

There was still one major problem, though. I needed a demo. I could show some code snippets on the screen, but without a real demo, it just wouldn’t have the same impact. I thought I’d have to write one. But I knew I’d never make the time and would end up rushing both the presentation and the demo. That’d just make for a sucky experience — and a sucky, stressful week.

Then it dawned on me. My buddy, Brian, had an awesome demo already! His CSS3 Digital Clock app would be perfect!

First, let’s see if I even get picked.

Two days later I got the email with the subject line: “Your jQuery Boston Conference 2010 talk is accepted!”

WOOHOO!!!

A couple of emails, chat conversations, and phone calls later Brian was on the speaker list, too!

This is gonna be EPIC!

And it was. I got a bit nervous in the middle and forgot half of what I wanted to say, but I think I got the major points across. Brian did an amazing demo, and several dozens of people came up to us later and thanked us for the talk. I guess that means it was a success.

Kudos to the jQuery team, to the conference organizers, and to the other speakers. The whole conference was a huge success, imho. I am quite honored to have been able to participate in such an awesome event.

For more about the presentation and OOCSS, check out some of these links:

Brian debuted the exploding mod of the digital clock at the show. (Very cool.)

Brian’s write-up after the event.

Brian, looking more like a GQ model, than a pirate.

Me, looking rather stressed. I think I was saying “yarrrrrrrr”.

Another link to the slides.

Rate me and Brian if you attended the talk!

The github repo for OOCSS.

cujo.js — OOJS, OOCSS, and OOHTML — Part 1 (OOCSS for Engineers)

John Hann — Tue, 31 Aug 2010 11:47:07 +0000

One of the coolest concepts in cujo.js is the introduction of Object-Oriented CSS into the Views and Widgets. I’ve seen several engineer’s eyes glaze over when I mention OOCSS, but don’t dismiss it as just a rehashed retelling of how to structure your CSS. OOCSS is a very powerful and efficient tool, especially when used in conjunction with Object-Oriented JavaScript and inheritable HTML templates.

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:


    
        1st Item
        2nd Item
        3rd Item

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:


    
        1st Item
        2nd Item
        3rd Item

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!

Firefox’s proposed Resource Packages spec blows!

John Hann — Wed, 04 Aug 2010 04:47:28 +0000

It’s no secret that one of the keys to a decent user experience is a responsive (fast) user interface. And the most critical component to a fast web app is minimizing the HTTP requests. So it’s no mystery that people are working on ways to solve this problem.

Firefox, of course, is one of the leaders in this area. Their proposal started out fine. Here’s a sample of what it would look like (if you didn’t read the article):

You specify that the file, /static/site-resources.zip”, contains the listed resources. JavaScript, CSS, and images. (I imagine SWFs and videos would also be options.)

But for some reason, this concise, nearly-valid implementation was trashed in favor of a terse, unfamiliar, and nearly unusable alternative. Here’s what the spec looks like now:

In this bastardization, the packages are specified as an attribute on the document element ( tag). Package definitions in the packages attribute are delimited by square brackets, and the resources within them are delimited by spaces.

WTF? Not only is this ugly and non-standard, but it also has some serious drawbacks. Here’s why:

Reason #1: Any non-trivial web app has hundreds of resources

The spec says that naming the resources is optional. However, not naming them causes the browser to block all further downloads until the resource package is downloaded and unzipped. So to gain optimal performance (not block), we’ve got to list every single resource? Not only is that going to be one hell of a large tag, but it also needs to be maintained every time a new resource is added to the app.

The real answer, of course, is to use a dependency-management and packaging solution. dojo.require and dojo.build do all of the work of resource packaging already. (require.js is a good start at dependency-management for the non-dojo world, but still lacks packaging. Admittedly, dojo only packages javascript and html templates, not css or images. cujo.js will also package css, but still not images.)

With dependency-management, resources are named where they are used, not in some other file. Having to remember to go back and list every resource in every HTML file is nothing short of a maintenance hassle.

But hmmmm. Maybe this is a not as big an issue as I originally thought. If I am using a dependency-management solution, my resource packages would consist of one javascript file, one css file, and a few dozen images. That’s still a lot of image files to maintain, but not as bad as maintaining hundreds of javascript and css files.

One of the reasons the browser needs to block is to allow for overrides. If package, pkg2.zip, has a resource with the same path/name as a resource in a package declared earlier, pkg1.zip, then the resource in pkg2.zip will override (replace) the resource in pkg1.zip. Therefore, the resources in the packages must be delineated — either explicitly or by inspecting the package — before the packages can be used.

Again, this override functionality is just duplicating dependency-management solutions. Object-oriented javascript allows us to override methods and properties. OOCSS allows us to override CSS rules in a different, but equally effective, manner. (cujo.js also allows for HTML template inheritance / overrides (OOHTML?).)

When done properly (small, concise OOJS, OOHTML, and OOCSS files) and combined with dependency-management, the download size should be exactly the same and amount of extra RAM needed by the browser should be small compared to the resource packaging solution.

dojo.require('pkg1'); // base functionality (large)
dojo.require('pkg2'); // overrides (small)

Reason #2: There’s no way to specify a resource package dynamically

This is a non-starter for me. I write client-heavy web apps. These apps are typically long-running and are served to the browser as a single page. In other words, the browser doesn’t load a new page every time the user takes an action. Google Docs and Google Mail are good examples.

Using dojo.require and dojo.build, I can package my apps into as many packages as I like. (They’re called “layers” in dojo.) This is especially important in a few scenarios:

the app will load a package only when needed
the user can switch “theme” packages dynamically
the user can switch language packages dynamically

If Firefox goes forward with the packages attribute on the tag, then I don’t see how this is possible. For example:

var html = document.documentElement,
    myNewPackage = 'pkg3.zip js/myModule.js images/myPng.png';
html.setAttribute('packages', html.getAttribute('packages') + ' [' + myNewPackage + ']');

Even if that did work (which I doubt it would), it would undoubtably be unbearably inefficient. Re-parsing, re-scanning, and re-analyzing every package.

The original proposal did not have this problem. It’s a lot simpler to just add a new tag:

var head = document.documentElement.firstChild, // assumes no comments before head!
    link = document.createElement('link');
link.setAttribute('rel', 'resource-package');
link.setAttribute('type', 'application/zip');
link.setAttribute('href', 'pkg3.zip');
link.setAttribute('contents', 'js/myModule.js; images/myPng.png');
head.appendChild(link);
 
// in dojo:
var head = dojo.query('head')[0];
dojo.create('link', {rel: 'resource-package', type: 'application/zip', href: 'pkg3.zip', contents: 'js/myModule.js; images/myPng.png', head, 'last');

So. Can it be fixed?

Of course. But, frankly, I don’t really care. For us dojo developers, all it’s going to help out with is images. And since we’re using less and less images and more and more CSS3, images aren’t such a big deal going forward. (border-image, border-radius, and gradient, FTW!)

But I guess, for image-heavy apps, there’s still a need. So here’s how I’d fix it:

First of all, abandon that dumb-ass packages attribute. It’s ugly, non-standard, and unworkable for the large apps that really need packaging. Go back to the tag. That was a much better idea.

Or better yet, use the