Jonathan Snook wrote a bunch of great stuff about this topic over at http://smacss.com/.
Also, take a look at Object Oriented CSS => https://github.com/stubbornella/oocss/wiki
In Ask HN: How do YOU define maintainable CSS?stubbornella
oocss
JavaScript2010–2012
stubbornella / oocss
oocss
Object Oriented CSS Framework
13Distinct people
17Mentions
0Explicit recommenders
6.2KGitHub stars
What to know before exploring
What it is
Object Oriented CSS Framework
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month17 dated mentions
Observed mentions: 2010-09-28 21:30:26 UTC to 2012-05-06 02:11:40 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Sep 2010 | 2010-09-01 00:00:00 UTC | 2010-10-01 00:00:00 UTC | 1 | 0 | 1 |
| Oct 2010 | 2010-10-01 00:00:00 UTC | 2010-11-01 00:00:00 UTC | 1 | 1 | 0 |
| Nov 2010 | 2010-11-01 00:00:00 UTC | 2010-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2010 | 2010-12-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2011 | 2011-01-01 00:00:00 UTC | 2011-02-01 00:00:00 UTC | 2 | 0 | 2 |
| Feb 2011 | 2011-02-01 00:00:00 UTC | 2011-03-01 00:00:00 UTC | 1 | 1 | 0 |
| Mar 2011 | 2011-03-01 00:00:00 UTC | 2011-04-01 00:00:00 UTC | 1 | 0 | 1 |
| Apr 2011 | 2011-04-01 00:00:00 UTC | 2011-05-01 00:00:00 UTC | 1 | 0 | 1 |
| May 2011 | 2011-05-01 00:00:00 UTC | 2011-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2011 | 2011-06-01 00:00:00 UTC | 2011-07-01 00:00:00 UTC | 5 | 0 | 5 |
| Jul 2011 | 2011-07-01 00:00:00 UTC | 2011-08-01 00:00:00 UTC | 1 | 0 | 1 |
| Aug 2011 | 2011-08-01 00:00:00 UTC | 2011-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2011 | 2011-09-01 00:00:00 UTC | 2011-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2011 | 2011-10-01 00:00:00 UTC | 2011-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2011 | 2011-11-01 00:00:00 UTC | 2011-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2011 | 2011-12-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 2 | 0 | 2 |
| Jan 2012 | 2012-01-01 00:00:00 UTC | 2012-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2012 | 2012-02-01 00:00:00 UTC | 2012-03-01 00:00:00 UTC | 1 | 0 | 1 |
| Mar 2012 | 2012-03-01 00:00:00 UTC | 2012-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2012 | 2012-04-01 00:00:00 UTC | 2012-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2012 | 2012-05-01 00:00:00 UTC | 2012-06-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
#OOCSS
Look into oocss folder for more informations
Read the full README on GitHubWhat Hacker News says
17 sourcesSome issues...
Even using the grid normally, it ends up using more horizontal space than on the viewport, forcing a horizontal scrollbar (Chrome 18).
Another problem: setting max-widths on units. Any proceeding units are handicapped by this and often just leave empty space to the right.
I also don't like the presence of three sets of classes when two would be appropriate. "ingrid" as the container, and "span-x" for each column division. And this is unavoidable, as you need to define "in-[parts]" in the container to even use the span-x classes. I understand that it's less work if you stick to equal parts, but this is not the majority use case in my experience.
I find the naming scheme awkward. "in-twos" and "in-thirds" instead of "in-halves" or "in-threes". Keep it consistent.
---
All in all, I wouldn't recommend this to my mother.
I use N
Read the rest
icole Sullivan's snippet in her github project,
https://github.com/stubbornella/oocss/blob/master/core/grid/...
(demo: http://oocss.org/grids_docs.html)
And it's been damn bullet proof, being used in production code.
I really like this idea, and it's one I wish I had time to work on myself. I think there's a real need for something like this.
I've come to the conclusion that a project like this would only be successful if contributors are expected to document WHY the code used is written as it is.
Without documentation (an example UI style guide, like the homepage of Twitter Bootstrap) it's difficult to see both the big picture and the purpose of the small details.
Twitter Bootstrap had a great home page right from the start – it served as documentation for the project, as well as a marketing demo influencing you to try it.
So imagine if the contributors to your repo were simply asked to follow a few guidelines, documenting their contributions (say, providing example HTML and using KSS to markup their CSS).
https://github.com/kneath/kss
http://www.ali
Read the rest
stapart.com/articles/writingainterfacestylegui...
http://www.engineyard.com/blog/2011/front-end-maintainabilit...
Maybe ask them to follow a few of the "Object Oriented CSS" principles, so that it's easier to mix and match parts from different folders:
https://github.com/stubbornella/oocss/wiki
Principles of separating the "structure" from the skin"; and separating "container" from "content".
i would avoid structuring your CSS like that. http://smacss.com and https://github.com/stubbornella/oocss/wiki will help you
In Knyle Style SheetsSeriously, lets take a step back and ask our selves do we need another CSS grids. As far as I can tell there are like 3 methods to grids.
Blueprint type grids(http://www.blueprintcss.org/), OOCSS/YUI2 (https://github.com/stubbornella/oocss/wiki), and YUI3 (http://developer.yahoo.com/yui/3/cssgrids/).
Why create new grids, lets make the old ones better, or explore new uses for them. Like many on this post I can't imagine there are very many good ways to go about this.
In Ultra minimal CSS grid utilityThis Framework is mix of my Malo CSS Framework(2008) http://code.google.com/p/malo/ & https://github.com/stubbornella/oocss/blob/master/core/grid/... naming system is used.
I'm to blame about display:inline in Malo that is actually wrong it should be *display:inline or even better _display:inline to resolve the double margin problem in IE6.
In Ultra minimal CSS grid utility"Am I the only one that doesn't understand everyone's obsession with CSS grids"
I saw a great talk by Nicole Sullivan on CSS last week. She said that many sites lack a meaningful high-level abstraction for their visual layout, and end up with a tangled mess of float, padding & margin declarations on every element. This complexity, she said, is more clearly and concisely handled at a higher, site-wide level and suggested using a grid.
I've wasted an insane amount of time pushing one element four pixels this way and another element three pixels that way, so I'm definitely eager to try a grid on my next project.
Links to her slides (with some other great info) and her grid framework:
http://www.slideshare.net/stubbornella/our-best-practices-ar...
https://github.com/stubbornella/oocss/blob/master/core/grid/...
In Ultra minimal CSS grid utilityThis still suffers from the rounding error seen here [http://i.imgur.com/DXjVN.png].
Otherwise, yup... it's a grid. Looks like they're setting the grid elements to display:inline... which seems weird and unnecessary to me? Block elements don't belong inside inline elements.
I hate to keep posting this, but I've been unable to find fault with this grid [https://github.com/stubbornella/oocss/blob/master/core/grid/...] code. .lastUnit spans the pixel gap on the rightmost, nestable, extendable, fluid widths.
The two are mostly the same idea, but I think the OOCSS project implements it better and works with more browsers.
In Ultra minimal CSS grid utilityOn the blog...
"If you have some .class { width:25% } that will make 4 columns grid (25% + 25% +25% + 25%). The problem is that you can't have precision px margins (gutter). So in the past you had nested divs or .something-like-this{width:24%; margin-left:1%}..."
"With calc() that problem is solved now we can have .class{width:calc(25%-10px); margin-left:10px} . And with that we can have the flexibility of the % and the px precision."
This was never a problem if you separated your layout markup from your content markup, like so.
<div style="float:left;width:50%">
<div style="margin:12px">Hello, world</div>
</div>
<div style="float:left;width:50%">
<div style="margin:12px">Hello, world</div>
</div>
Bear in mind that calc() has terrible support [http://caniuse.com/#search=calc]. Box-sizing fixes the problems
Read the rest
addressed by this "framework" without deferring to an expensive and inappropriately used calc() property.
I see no reason why anyone would use this over a grid model such as this [https://github.com/stubbornella/oocss/blob/master/core/grid/...].
Float has no say on the matter with regards to width. I use an extremely simple 14 line grid system that uses % widths, is nestable, and works in every browser I test it against.
Not surprisingly this "system" (this word really makes it sound more than it is) can be found on one of the CSS Lint creator's Github: https://github.com/stubbornella/oocss/blob/master/core/grid/...
While simple, it's definitely way more elegant than some of the grid systems I've seen built, such as the popular 960 fluid grid layout that ultimately generated nearly 800 lines of CSS for 5 columns.
It also goes hand in hand with the core principles of OOCSS, which essentially states to extend classes and use multiple classes per element.
In CSS LintSo the prime example of what not to do is the sidebar/h3 example. Then the example for what to do is a simple example from Facebook.
How about showing us how to actually solve the first problem?
For anyone wanting to know more about this presentation, check out her Object Oriented CSS: https://github.com/stubbornella/oocss
In CSS: Our best practices are killing usSuprised no-one has mentioned Nicole Sullivan's (amongst others) Object Oriented CSS (OOCSS) project: https://github.com/stubbornella/oocss/wiki
She used this approach at Facebook (and Yahoo, I think?) to successfully tidy up a huge code base of thousands of CSS files down to a more manageable few.
I attended her workshop at Webstock and since then had a chance to put it into practice on a 'get it up quick' green fields project (http://chchneeds.org.nz). I must say I was really pleasantly surprised at the way this approach just avoids a lot of the pain points, as a web developer/coder (ie not an html/css guru) I so often face when just getting the simplest things to 'work'.
I guess the hardest thing for me to get my head around to was that to make things more modular you had to let go (a tiny bit) of being so religious about 'semantic htm
Read the rest
l' as a requirement for the HTML, but I think its worth it to get your CSS a whole lot more modular and 'pluggable' together.
Still a bit more work to do, IMHO, but I'm definitely going to be monitoring this project closely.
Nicole Sullivan's site: http://www.stubbornella.org/content/
There are better ways to manage CSS bloat.
See Nicole Sullivan's Object-Oriented CSS approach: https://github.com/stubbornella/oocss/wiki
In How to Manage CSS ExplosionI like the term "Mockup-Driven Development". This is a problem I've been thinking about for quite some time, and I think the author describes it well. There's clearly room for progress in the integration between client-side HTML/CSS designers and server-side programmers.
I've found two things help integration greatly: "Super Templates" and "Logic-less Templates".
Super Templates: e.g.: building a single page template for the entire site
This a technique I learned from Nicole Sullivan's "Object-Oriented CSS" https://github.com/stubbornella/oocss/wiki/FAQ (see the section: "Why have a single template?"). A colleague of mine has nicknamed them "super templates".
Building everything in a single template provides essentially an "integration test" for your HTML components. CSS conflicts are made visually obvious.
Most likely, you would build ea
Read the rest
ch HTML component in isolation, and stitch them together into such a "super template" via {{< include}} or similar. To avoid CPU overload, you toggle on/off HTML/CSS as needed for a given test.
Logic-less Templates: e.g.: {{mustache}}
http://mustache.github.com/
Mustache templates are language-agnostic. You only have to build them once, and you can use them everywhere.
Mustache views provides a Mustache template with content. So within one app you might use the same Mustache template server-side (with a Ruby view), and client-side (with a JavaScript view).
Because of this flexibility, the Programmer and Web Designer can use the same mustache templates, using a view appropriate view for their needs (either the real view or a "stub").
The Web Designer would use a "stub" view. It has fake data structures, dummy lorem ipsum. Just enough to build a template.
The methods of this "stub" define an interface which can later be implemented in the real view, at the Programmer's convenience.
This results in the same "Mockup-Driven Workflow" the author describes, with no additional libraries required. The Web Designer works (in the browser) on the templates, using JavaScript view stubs. The Programmer uses the SAME templates, coupled with his server-side views, in the actual application.
Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.