Seems like this style is best suited to cases when a designer won’t always be intimately familiar with the CSS, isn’t changing it on a daily basis, will be re-visiting projects after several weeks or months, etc.

If you’re very focused on a small number of properties and working with the CSS of each on a very frequent basis, then you could probably skip this method of coding.

I agree with you that the structure of OOCSS is very complex (I had a look at the source and couldn’t believe how many files and folders there were!)

As I said above though, I don’t think the lack of semantics is an issue – a framework by definition cannot know the context in which the class will be used in advance, so cannot give a class name that will be semantic for everybody.

I have found the best thing to do is just use a class name that describes what it does. So if your class transforms a list of links into tabs, just call the class ‘tabs’. At least then the designers/developers know what that class is there for.

Any “framework” that specifies the use of classes with meaningless names such as “unit size2of3 lastUnit” and which, while claiming to be a CSS framework, states that its non-semantic classes should be inserted via a serverside script or JavaScript (huh?) just isn’t worth taking seriously.

Others have mentioned semantics – what on earth is semantic about classes such as gMail, gCal, yahoo, myYahoo, oldSchool and the like? Anyone wanting semantic output would not touch OOCSS.
Ideal in a team environment? Maybe, if the team keeps a reference guide handy to explain the jargon.

With no source order, no semantic document structure, and no apparent consideration for accessibility, OOCMS has a very long way to go before it should be considered worthy of promotion by SitePoint.

The name has managed to generate lots of interest, however, so from a marketing point of view it was an excellent choice.

This is really just a ‘modular’ approach to CSS, which I would consider best practice anyway.

The discussion it has generated has made for some really interesting comments, so in that respect this is surely a good thing. I’m not sure it needed a whole framework and code built around it. It is just a methodology and should be discussed in that sense.

As a methodology, this contains some good ideas. People should definitely be trying to create more reusable CSS. It is a fact that many website contain largely similar items – tabs, vertical nav, sidebars,headers,comments etc. It would make sense to create some classes that could be used to style these elements quickly. I’m sure a lot of people just copy and paste from the last project, but this methodolgy would advocate creating some reuasable ‘modules’ with consistent naming conventions, markup paterns and classnames.

The arguments that the class names are unsemantic doesn’t hold water. Using unsemantic class names doesn’t lose any semantic meaning, it just doesn’t add any either. If you’re really concerned about it, why not just add some extra class names that ARE semantic? The fact is that if you are creating reusable code, you can’t predict in what context it will be used in future, so the best choice for a class name would be something that describes what it does. I wrote a blog post about this a while ago (http://dazzl.co.uk/blog/don-t-sweat-the-unsemantic-stuff).

I Mean, the tag BODY is parent of all DIV tags of your page, so any DIV element “classified” with any CSS class will benefit of any BODY CSS class applied. (Am I clear ? I am not sure, but it’s the idea, and it’s a good one !)

Thanks to the SitePoint Team to broadcast Good(Best?) practices to avoid monstrous CSS class definition file and incomprehensible.

Cheers,
Nicole

@Jez You are absolutely right, it would be much better if browser supported inheritance within the CSS itself. More on that later.

Calling it OO may irk some of you, but it doesn’t need to be .net, php, or js in order to be OO. In fact, in order to be object-oriented CSS it needs to specifically be CSS and do what CSS was intended to do, which is style web pages. It has many of the components of OO including encapsulation, inheritance, polymorphism, modularity, abstraction. No, it doesn’t have methods. CSS doesn’t need methods.

The cool thing about the cascade is that you can do things like multiple inheritance, that would be a mess in ordinary programming, but with the cascade are neatly taken care of.

Keep in mind that this article is an intro, a dip into the subject rather than the full treatment. You might also want to check out this video on the subject or at least look at the code.

Spend a few minutes looking into it before whining about what a horrible atrocity the name is, it’s nothing new, etc.

In other news, Mozilla Firefox isn’t _actually_ a small furry critter who loves in forests.