Skip to content


Subversion checkout URL

You can clone with
Download ZIP


stubbornella edited this page · 43 revisions

Whoa, you have lots of questions! I’d better start recording the answers if I want to scale better.

Should I use IDs to style my content?

When you reuse an object in the same page (or on the same site if the cache is working properly), it is a performance “freebie”. Styling using IDs makes it impossible to use the same element twice on the same page. @cgriego (twitter) compared it to singletons, which sounds accurate to me. There may be cases where you want to style using an ID, like header menus that are very specific, in this case you can use an ID to sandbox the particular element and be sure that the code written for it doesn’t impact the rest of the site. Think carefully before you choose an ID over a class, it is really hard to predict what people will do with HTML built from your CSS as the site evolves. If you have a choice, leave things as flexible as possible.

I am considering removing the ids from head, body, and foot in my template. Someone could have multiple main content areas. Multiple site headers and footers are more difficult to imagine, but I bet there is a designer who can dream up something like that, so the IDs are very likely to disappear.

On the other hand, ID hooks are great for linking. Put them in the HTML, just don’t use them for styles.

Designers can’t do OOCSS, can they?

Yes, designers instinctively understand objects, it is much more concrete than the way most people are currently coding CSS —layers of exceptions (think, there was an old lady who swallowed a fly). In fact, they love OOCSS for two reasons.

  1. It allows them to ramp up a lot faster when creating complex high traffic sites. They don’t have to bother with understanding the structures until they are reasonably competent and comfortable with basic syntax.
  2. When learning CSS, they never have to create the ugly “hello world!” website. Designers care very much that their work is beautiful. If they have to make something ugly, even for the sake of learning, they will very quickly get frustrated and annoyed. OO-CSS allows their work to be beautiful at each stage of the learning process.

Designers are smart. We need to give them credit. They may speak a different, non-engineering language, but often geeky language excludes people in a way that is kind of ugly. We can do better than that.

I’m a Front-end Architect, how do I teach this to my team?

As the architect, you should write the structure object; set up how the rounded corner box is created, positions all the presentational elems for corners or other features, and deals with browser differences. Newbies write the skins for these modules (borders, colors, background images, etc).

I built large scale sites (1000s of pages, millions of visitors) using the OO-CSS method. It scales well and, when done correctly, it means that the individual components a newbie would be working on are relatively predictable. Code review is easy because there are clear rules about acceptable ways to extend objects. This kind of feedback makes new developers productive really quickly.

I managed a team of front end developers at FullSIX (a web marketing agency in France) who are among the most talented people I’ve ever worked with. At some point our success meant that we had far more work than we could handle. It is very hard to hire front-end experts (there is no school for this stuff!), so I started an internal internship program where designers who were interested in exploring code (but had little to no previous experience) could come work as junior members of our team for one month.

  • Week 1: They learned about semantics and built html from existing CSS. Learning to build new pages without writing more CSS, HTML syntax, multiple classes, validation, semantics, intro to code review, etc.
  • Week 2: They built simple content objects (headings, lists, etc) for a week. Learning CSS syntax, how to extend objects, colors, % sizes for text, etc.
  • Week 3: they were building block skins. Borders, colors, background images, basic positioning, sprites. They worked with an amazing senior developer who answered a ton of questions and really helped them scale the learning curve. He also happens to be a very talented code reviewer.
  • Week 4: they were productive members of my team building skins that were production ready.

Their code is live on a client website. It is as good as anything written by the senior developers, maybe better because they didn’t have to un-learn bad habits. :)

Getting Started: How do I work with these files?

Two files, libraries.css (reset and fonts from yui), grids.css and template.css are ready, the others are still extremely unstable.

  1. Open template.html and save it as a new file.
  2. Adapt the number and width of the columns by extending those objects. You only need one template for your site, even if you have pages with different columns, because the columns are objects like anything else. You can think of them as optional regions, you may have 0-n left columns. See template docs for more information.
  3. Use grids to break up any of the content areas into smaller chunks. See grids docs for more information.
  4. Add content. Hint: This should also be OO.

How do I deploy this on a live site?

Keep in mind that the CSS is still evolving, I may change things based on feedback I’m receiving.

I’ve broken up the CSS files into modules like grids and template. On a real site you should remove unnecessary comments and reduce HTTP requests, or the site will be super slow. This means you need to combine CSS files into one larger file. I do that via nested comments, to keep the CSS organized. Finally, run a CSS minifier as a part of the push/deployment process to remove stray comments.

Should I edit these files, or overwrite them with my own stylesheet?

I wouldn’t edit grids, template, or libraries. A lot of testing has gone into getting those just right. If you want to customize, think about extending the basic objects instead.

Pink is not my color! What do I do with content.css?

You may well want to edit content.css. Go ahead, change colors, font sizes, capitalization. Just keep in mind that this file is rapidly evolving and I don’t have any docs yet to show you how to do it correctly. I’m working on it, I promise.

I need more than six (h1-h6) headings on my site. How do I add more?

If you want more than six heading styles, extend the heading objects by adding a new class.

.category{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}

What not to do:

#mySaleModule h2, #mySaleModule .h2{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}

How do I extend an object?

If you want to extend an object, for example a 160px left column, rather than the default, you should add an additional class to the column.

<div class="leftCol gMail"> ... </div>

If the default and extended widths of columns or pages don’t match your site, you can extend the column to allow a custom width.


myColumn extends column objects to allow for custom column widths.


And the HTML

<div class="leftCol myColumn"> ... </div>

Don’t think of this as overwriting my classes, but rather extending the objects provided by the framework. I give you columns, headings, and other objects. You can extend those objects by adding another class that only specifies the differences between my base object and your implementation of the same. Mixins may be a good analogy here.

What not to do (because it will make it harder for you to upgrade to newer versions of my framework):

.leftCol{… custom css here …}

Unused Styles. My site will never have a 160px gmail-style column, is it ok to remove it?

Sure. Removing objects or extensions to those objects is perfectly reasonable. Just keep in mind that it is hard to imagine what HTML someone might build with your CSS when a site is still evolving. Premature optimization is a danger.

Why have a single template?

In object oriented CSS, an important goal is to have a single template from which all pages are built. This eases CMS development because by having a single starting point all pages can be made into any other page. Users of the CMS do not have traps in which a page they have built cannot be morphed into a different page type. Another goal of and OO template is to have each section (column, header, etc) control it’s own destiny. Practically, that means that if you want to add a left column to the template, the only required action should be actually adding the column to the HTML. You never want to write CSS in such a way that changes are required higher in the DOM tree in order to make child elements behave properly. Looping through the dom is costly for CMS development.

Is this semantic? Will I end up with classes like .formYellow or tinyBlueH2?

OOCSS can be written in a semantic or non-semantic way, it is up to you to create modules like errorMod rather than bigRedModule. I’ve chosen class names with a few goals in mind (in no particular order).

  • Brevity – every byte counts, so I kept classes as short as possible
  • Clarity – expected behavior/style should be immediately obvious
  • Semantic – what an object is matters more than what it looks like. How will it be used in the site?
  • Generic – the name should be true for most sites. Overly specific names reduce the number of use cases or cause semantic classes to be used in a non-semantic way.
  • Screen – Different views might be provided by mobile or print stylesheets, however they override the default screen view, so the classes chosen are screen specific when there was a conflict. This simplifies development.

The code and docs are a framework, an example of OOCSS. I can’t predict what you are going to put in leftCol. I could call it navigation, but that my not be true for your site. Sometimes these important goals are in opposition to one another. In those cases I’ve fallen back on pragmatism and made a judgement call. Nothing can replace a clever developer making the right choice in a given situation.

What about other libraries/frameworks? Does this only work with YUI?

In an ecosystem with a lot of frameworks and libraries, YUI stands out as an example of professionalism and scalability. I compare myself to them because I am continually impressed by the quality of their code and documentation. OOCSS isn’t really a framework, though I’m creating one here as an example, but a way of writing scalable, sane, maintainable CSS. Maybe the best analogy is a new language. Ultimately, it is JavaScript library agnostic and I hope to contribute code back to YUI and other frameworks.

A framework for CSS is overkill! Shouldn’t we code everything from scratch?

Do you rewrite the math class every time you need a random number generated?

CSS is hard, not because it is broken , but because it is a legitimate technology requiring expertise to architect correctly. It would be foolish to reinvent the wheel for every site.

How can I help?

The best way to get involved is to start using the code (libraries, grids, fonts) and submit bug reports and feature requests. I also started a OOCSS google group to facilitate discussion that is more complex than 140 twitter chars allows.

Something went wrong with that request. Please try again.