graphicpush

Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Redefining the "C" in "CSS"

In changing my habits around writing CSS, I’ve slowly adopted an object-oriented approach that outright rejects the “cascade” part of “cascading style sheets”.

Over the past two years, I’ve been slowing transforming the way I write CSS. When I first started experimenting in 2003ish, there were no best practices around performance and maintenance because no one had scaled CSS to a true application level of, say, Facebook. So when you wanted to style an element, it was a game of inefficient hyper-qualification:

#main #left-column .calendar h4 { color: red; }
 

This style of writing CSS is a road that leads to many dark places, namely style repetition, file size bloat, reliance on the cascade to solve poorly thought-through models and the temptation to !important everything. When I started a new site, I simply started writing CSS in the natural order of its appearance. So files looked like this:

#main { some: styles; }
#main #left-column { more: styles; }
#main #left-column .calendar { even more: styles; }
#main #left-column .calendar h4 { you: gotta be kidding me; }
 

And then further down the file, years later, I would add this:

#main #left-column .widget h4 { please: work; }
 

This is all rubbish. My bad habits started from the get-go, and it’s taken a long time to unravel them. Here’s my current thinking:

  1. If I’m relying on the cascade — at all — to dictate how an element is styled, I’m doing it wrong.
  2. If I’m using an #id in the element path, I’m doing it wrong.
  3. If I’m using !important, I’m doing it wrong.
  4. If there are more than three levels in the element path, I’m doing it wrong.

I’ve been thinking about #1 specifically for awhile.

In the Old Model, I would build out expansive, detailed styles for each component, so a button in a column would have styles duplicative of a button in the primary contact form: background-color, text-align, etc. In the new model, elements are built up with classes, so the styles are cumulative. Simplified example:

.button { border-radius, box-shadow, border, basic typography }
.major { background: obnoxious, font-size: huge }
.minor { background: subtle, font-size: small; }
 

The HTML would be something like:

bc. 
 

These button styles could also be applied to an anchor element, or something like a <span> that’s being used as a pseudo-link by JavaScript.

By creating class-based rules that are independent of DOM context, we have a style sheet where every rule could be shuffled into a random order and it would not affect the browser’s rendering of an HTML document.

This is easily tested by writing CSS upside down: write your freshest rules at the beginning of the file, not the end. Building re-usable CSS objects against the gravity of the cascade provides instant visibility to cascade conflicts; if a new rule at the top isn’t working, you know you have something further down that is competing. Object-orientation becomes encouraged, and bugs are immediately squashed. After new rules are vetted, they can be moved to the appropriate location in the CSS file.

Object-oriented CSS by its nature does not need the cascade. Thus I’ve started to rethink the “C” in “cascading style sheets”. I’m not 100% sure what the word is, but something like cumulative, compiled, cooperative, collated or concerted would all work nicely. I don’t expect this to catch on, but it has helped me focus on crafting highly efficient and modular rules that add up to something greater instead of heavy rules that squabble with each other and require intervention to untangle.

, ,

commentary + criticism

Micah

wrote the following on Thursday March 15, 2012

What you’re talking about is something I’ve recently began doing myself – Object-Oriented CSS or OOCSS. The best person I know that evangelizes this stuff well is Nicole Sullivan. The best result that I’ve seen from this style of coding CSS is that it allows your sites to scale using the same rules, so long as these rules are apparent from the beginning.

I have to disagree about the idea that C no longer stands for Cascading, because by my own experience, there are still certain things that you might want to have shared between elements. Fonts or colors for example. For that, I’d rather repeat the classes and list the fonts once, rather than list the fonts in every class. Granted, I typically don’t do this unless I catch the same attributes be used in at least three elements. And I suppose it all depends on what you’re comfortable with.

But srsly, go google Nicole Sullivan. She knows her shtuff.

Winston

wrote the following on Friday March 16, 2012

This is a really helpful post, thanks!
I’m just learning CSS and had sort of intuited that there must be an alternative to the cascade.
Your cumulative OO approach makes sense.

Ramesh

wrote the following on Saturday March 17, 2012

Thanks Kevin! I am not a technical person, but will share your CSS experiments with my program guys.

Kev

wrote the following on Saturday March 24, 2012

I found this a really interesting read and mirrors some of my own feelings about the way I’ve been writing css for a while (badly). I’m definitely going to try and apply some of these ideas myself, I’ve also been feeling that my css should be more object orientated. Great read, thanks.

Lasha Krikheli

wrote the following on Friday March 30, 2012

I’m with Micah on this one. I have adapted a lot of “modular” CSS techniques as mentioned in this article and by Nicole Sullivan, but the “cascading” nature is still a very important part of creating efficient and easy to manage complex layouts.

A good balance of object-oriented techniques and the very nature of CSS is the best way to go, I think. :)