Saturday, February 28th, 2009

Nicole Sullivan’s Object Oriented CSS

Category: CSS

Sometimes I’m so focused on JavaScript that it becomes a bit of a hammer for me that I try to use it on all problems. I forget about the power of CSS and what it can do. I recently met Nicole Sullivan at Web Directions North who is a CSS guru, especially around performance. She told me about an idea she’s been working on called Object Oriented CSS, and she’s just released open source code and documentation on the idea on github. From Nicole:

My [Object Oriented CSS] grids and templates are open sourced on github.  They have all the functionality of YUI grids plus some important features.

* Only 4kb, half the size of YUI grids.  (I was totally happy when I checked the final size!)
* They allow infinite nesting and stacking.
* The only change required to use any of the objects is to place it in the HTML, there are no changes to other places in the DOM and no location dependent styling. Eases back-end development and makes it a lot easier to manage for newbies.

…My prediction is that you’ll be writing complex layouts in less than 24 hours without adding a line to the CSS file.

More on Object Oriented CSS:

How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

Two main principles

1. Separate structure and skin
2. Separate container and content

Posted by Brad Neuberg at 6:00 am

4.2 rating from 49 votes


Comments feed TrackBack URI

Wow. I’ve been struggling to put words around these “OO” separation concepts for the past year! Awesome job Nicole!

/me deleting unfinished blog post (but not unhappy about it)

Comment by unscriptable — February 28, 2009

Is this library of any use to people doing fluid layout? Any time I see the word “grids,” I worry it’s all for fixed layout.

Comment by Nosredna — February 28, 2009

Well-said. Determining “global” components is probably one of the more important parts of getting your code in order, as is using a good container format like the YUI standard module (.hd/.bd/.ft). I’ve been using .className rather than div.className (slide 51) for years, following the thought that eventually code would change or a new element may want to inherit the same style.
@Nosredna: I think people tend to assume fixed-width with grids, but that doesn’t mean you can’t have a fluid/flexible-width grid-based layout – eg., from 780px to 1280px min/max-width, using EM or percentage-based widths for the individual columns.

Comment by Schill — February 28, 2009


I used YUI grids in one project and it was very much geared toward fixed. I don’t doubt that the lessons here apply to fluid as well, though.

Comment by Nosredna — February 28, 2009

Oops, something I forgot and an idea others have mentioned for a “wish-list” – it might be interesting to be able to define and use variables or constants within CSS, as another way to increase reuse and make maintenance easier. eg. background-image: $myValue; or similar, where $myValue = “url(/path/to/image.png)”;

Comment by Schill — February 28, 2009

Nosreda : fluid layout is a non-sense.
Not only it dramatically makes design more difficult (and sometimes impossible for complex layout). But it also degrade accessibility and usability :
Having your text reflowing when you resize your browser completly kill your site.

Even if you don’t resize, having the text span on a large width is also a big no-no : over 15 to 18 words per line legibility is greatly reduced. It’s a biological fact, print designers have been aware of that for centuries.

I don’t understand all this fuzz about fluid design, it’d ridiculous. Just try to browse slashdot using a high resolution screen, it’s a real pain.

Fluid design is not a good practice, ask any ergonomic pro. It’s true for any other media, it’s also true for the screen… Websites should scale, not span.

Comment by ywg — February 28, 2009

@ywg : while I agree with you that fixed width is better for content sites, fluid layout can be very important for certain web applications. There’s a reason why most of your desktop apps are fluid. Try to imagine Excel or Thunderbird or Photoshop with a fixed-width UI.

Comment by fortybillion — February 28, 2009

@fortybillion : you’re right, but even on these applications the design is not really “fluid” content zones and panels are fixed. They just have an extensible workspace : cells in excels are fixed, cols in datagrids are fixed, panels in photoshop are fixed and docked…

And in modern OS, UI are now vectorial and also scale.

Comment by ywg — February 28, 2009

PS : the only really “fluid” application I can think off are calendars

Comment by ywg — February 28, 2009

>>Nosreda : fluid layout is a non-sense.

Tell it to, which fills the page in a very useful and pleasing way.

Viewing a fixed site is frustrating to me. I much prefer fluid, although I agree that for some sites (small brochure sites), fixed makes sense.

But that wasn’t the point. I was merely asking if this ooCSS was applicable to fluid or only to fixed.

Comment by Nosredna — February 28, 2009

@Nosredna, @Schill, @Nosreda, @ywg,

If you want to have a site that can be 1,2, or 3 column (like every site on earth) the middle column needs to be fluid so you can have one base starting template. This, of course, means the grids have to be fluid. After that, controlling the width of the overall container can be done in a fluid, em, or pixel based way depending on the site/application.

I’m agnostic (well, I don’t like layouts that grow with EM text size, but that is a personal choice), sometimes fluid is better, sometimes fixed, so the grids do both. There is a fully liquid example in the docs. (gmail style)

The base templates are: fully liquid, 750px, and 950px. It is easy to extend the objects to create other sizes. Your class would extend the main, leftCol, or rightCol objects — the new class only changes the width, the base class takes care of all the rest of the functionality. This is part of the high performance aspect, you don’t repeat code.

The grids are all percentage-based, so you can put them in any size container and they adapt. Sub-pixel rounding errors are taken care of by the “context de formattage” on the last unit in any line.

@Schill I also want to add a server-side include of any presentational elements so there isn’t a lot of cruft in the HTML. Processing the CSS file for variables like text color might also make sense. Next up for me is tackling blocks, the YUI standard module format (.hd/.bd/.ft) will be key to getting that done in and OO way.

Comment by Stubbornella — February 28, 2009


Thanks for the information.

Comment by Nosredna — February 28, 2009

@Nosreda :
Go to amazon and zoom back of 50% (or use a dual display)…
The layout feels “pleasant” because you’re on average resolution. On anything higher than 1500~1600, it’s unusable.

People designing fluid layout believing it’s better for large screen, but users with large screens are forced to resize their browser down on those sites…

Comment by ywg — February 28, 2009

>>People designing fluid layout believing it’s better for large screen, but users with large screens are forced to resize their browser down on those sites…

I resize my browser down more often on fixed sites because of the waste of real estate.

Comment by Nosredna — February 28, 2009

I’ve often questioned the usefulness of CSS frameworks since most of what they do is usually pretty basic, but this one looks really good.

Comment by DomainSuperstar — February 28, 2009

On an upcoming redesign of the w3c site I used an alpha version of my OOCSS to create a mobile view and normal view. Mobile is single column liquid. Screen has a fixed width navigation column and a fluid main column. The system makes it very easy to offer both user experiences because you only need to change one class.

Comment by Stubbornella — February 28, 2009

Stubbornella, what do you mean in slide 62 when you say “Proximity should impact the cascade” ?

Comment by ywg — February 28, 2009

@ywg It is about controlling the cascade. Let me give a concrete example. I have a Ducati module and a sale module, and I nest sale inside ducati in the html. If I’ve written my CSS correctly, the rules for the two modules should be the same strength (specificity).

Unfortunately, the sale module will inherit the Ducati module rounded corners or other details if the sale code is before the ducati code in the css file.

Tomorrow, or on another page, the nesting might be inverted, for example a sale page might highlight Ducatis within the sale module. Changing the order for one use case would break the other.

Better browser support for E > F (child) selectors is one solution, but it would bloat the code a bit because you would have to specify all the elems between your module and the part you are trying to style.

Modules are the next piece I’ll be working on. Stay tuned. :)

Comment by Stubbornella — February 28, 2009


Having your text reflowing when you resize your browser completly kill your site.

In my opinion, I love the fact that text gets reflowed when I resize the browser instead of having the site scale. When I view a website and I think the text size is too small (either by design or I’m showing the website through an overhead projector) I love to jack up the size of the text by 1 to 2 notches for ease of reading. But I don’t want to scale the website, because then I would lose view of the sidebars and the overall design. I would be sacrificing the total experience in exchange for readable text. If the website is fluid, it is the same layout and design as intended by the designer, except the text is slightly larger.

Comment by Jordan1 — March 1, 2009

Is this the video that the slides are used in

Comment by emehrkay — March 1, 2009

uml for css? please.

i still think that most of css could be replaced by a handy layout tag called ‘grid’ that behaves like tables. if people actually tried to build a client side gui they might learn to look beyond the webs limited technology set.

Comment by ilazarte — March 2, 2009

A quick note: It looks like pages in the sample files are looking for “page_layout.css” which is actually named “template.css” in the css folder.

I’m looking forward to playing with this stuff when I get out of work. As luck would have it I’m about to embark on a redesign of my personal site.

Comment by jsutcliffe — March 2, 2009

@emehrkay Nope. The podcast and video are still being produced by Web Directions North and Yahoo! Developer Network respectively. The other video is a presentation about design performance I gave for YUI theater.

@jsutcliffe fixed. Thanks!

Comment by Stubbornella — March 2, 2009

@ywg – I generally agree but thinking about new devices (iPhone, Android, etc) where the size of the screen could be 260×200 to 480×360 I think fluid layout is a must. Then we should consider to set a maximum width for every other resolution, like 640×480 or 1280×1024 ?
I cannot imagin a full HD fluid sit, anyway :D

Comment by WebReflection — March 3, 2009


Comment by boon — March 13, 2009

Hi Nicole

What do you mean by:
Design modules to be transparent on the inside

Also, where can I download OOCSS. I tried to do it from git but I am getting a 406 error on the download button.

Thanks in advance

Comment by AmyVarga — June 3, 2009

OO ? why this name ? it makes no sense. I don’t buy it. May be “engineered css” . Random names to create a buzz word, come on.

For the debate regarding Fixed vs Fluid min-width max-width are the answer :D

Comment by redben — October 22, 2009

Leave a comment

You must be logged in to post a comment.