Testing Object-Oriented CSS (OOCSS) for easier CSS development
Let’s face it: developing CSS that should work across various web browsers and platforms is hard, and could prove to be quite a challenge. This is where Object-Oriented CSS (OOCSS) steps in.
What it is
OOCSS is being developed by Nicole Sullivan, with a background at Yahoo!, who now consults for Facebook. The objective is to make CSS development as stable, modular and, very importantly, predictable as possible.
There are a number of different modules, where the most important parts are good CSS resetting (taken from Yahoo!), template and grid handling. However, there are also parts for tabs, talk bubbles, content media etc. The best way to see it in action is to go to the OOCSS page at GitHub to watch and download the examples.
What I like
I have been working with the base files for my current project, to evaluate it and also make things easier for me. Having a good framework for your basic CSS is vital in any web site you will ever build. You will get a consistent result, and instead of building the same things over and over, you can put your time and effort into what will make that specific web site into the best possible.
OOCSS is extremely easy to use, has overall worked flawlessly, and extending the good base is very simple. I also like it being very light-weight (my combination of resetting, template & grids weighs in just under 5 kb), which means my own web site-specific CSS becomes much easier to write, and it becomes much smaller because of not having to write redundant CSS.
What I don’t like
As you might be aware of, using good semantics is very important to me, and when it comes to both elements being used as well as the naming of CSS classes, I believe it should contain a meaning for what it will contain. OOCSS contains class names like
.h2 etc. And to me, and what I believe is to be in line with the notion of the semantic web, is that one of the fundamentals with CSS class names is to not use class names which describes the actual presentation/layout, but rather what it will contain.
And fair enough, I think one of the choices behind this was to make it easy to beginners, but still, when you end up with code like
<h1 class="h2">, that’s just wrong to me. No class name should ever be named after an actual element name if you ask me (especially not the name of another element).
I got to meet Nicole at JSConf.eu, and naturally had to ask her about her choices for class names. She said that she thought it was ok to also use “visual semantics”, i.e. class names that would describe how it would actually be presented. Trying to be open and understandable, I could somewhat see where she was coming from with this.
But, I suggested using other names that would have more meaning and be easy to understand at the same time, like
.complementary etc. The reply I got was that she had tried it, but “It was too hard for people to remember it”. And that I’m mot just buying. Sure,
.rightCol might be a tad easier to remember, but just going the easiest route time doesn’t always make it right.
So, in my files, I use class names that convey actual meaning.
Despite my little rant on class names (which you can easily change to whatever you want), OOCSS is quite exciting, and so far I have experienced good results with, and the possibility for me to focus on more important things! I definitely recommend you try it out, and give Nicole any input or feedback you might have.
I spoke to Nicole when she was in Amsterdam for the Fronteers 2009 conference about trying to make mark-up resistant to errors and easier to reuse. We both have a similar approach in dealing with teams with various competency levels. I do however have a big problem with her 'visual semantics' and do not permit it in my projects. Coming up with classnames so that they'll be reused is always a problem. So her stance is somewhat valid because this compromise in really large teams results is more stable markup.
So it's more of an edge case because how many of us work in such large teams, not that many I'd wager.
I agree with your opinion about class names. But i think there exist always classes in a layout which don't have to do with sematic. Like .col2, which is just how it's called: the second column. There can be different things in this column and the can change over the sites. In this class can be another, like .news-ticker. Here it makes sense to give a "sematic name".
Also, when you work with a CSS framework, .col2 exists mostly and with it, it's CSS definitions. But the content in .col2 is mostly not the same in the different projects. In one project, there is the navigation inside, in another a news ticker, and in a third, just some advertisment.
But when you call .col2 always .cal2 you know also after two years, how the basic setup is made for this column, without long looking around in Firebug 😉
I used the CSS framework YAML ( http://www.yaml.de/en/ ) for a lot of projects. It's great to have a framework that brings everything you need for your daily work. You don't have to care about all the browser bugs and you can use your time just for the specials in a layout.
Too bad about the unsemantic class names. I was quite interested when I heard about this project, but that view on things makes me less so. It clashes with my view of how you should develop modern web sites. Still, I will try to give this chance if I get the time, because the general idea and intent is still very good.
This is why I use a type of CSS constants. It allows me to create "classes" with CSS and then apply them to any selector in the CSS:
margin: 0 0 10px;
border: 1px solid #333;
#recent-comments = $white-box;
#calendar = $white-box;
It also allows me to structure my CSS modularly, ie I can keep the recent-comments code in a recent-comments.css-file and the calendar in calendar.css but still take advantage of the same CSS.
I've built up quite a set of handy constants over the past years.
I've been working with OOCSS-like implementations for a few months now. Most of my work has been for our company's websites, which are quite specialized and use very similar components, so I've been using parts of Nicoles OOCSS framework (grids, most notably) along with some YUI stuff, and a bunch of my own code and patterns derived from our rich site history, all within the spirits of OOCSS.
What I've learned is to let go of some of my über-semantics fanaticism in favor of rapid development, consistent naming and ease of implementation and maintenance. Using less semantic names and classes is definitely needed to avoid location specific code that can't be re-used (within or between projects).
Another criteria that I have to deal with is that a front-end developer shall implement the design for each component once, and then anyone able to write (good) HTML and read component documentations can plug-and-play everything without touching any CSS (especially to make location specific exceptions).
Of course, how semantically you can do it heavily depends on the sites you're building–I myself build sites that I have to maintain and do regular new development on.
Hey duuuude! 😉
Of course I've used your constants, and I've also had problems with that approach. When we used them for box decorations we came in to such a large amount of selectors that IE just didn't want to play and the CSS broke–so many location specific modules using the same rules/constants.
It can be nice to use with small site where you don't have that many repeating styles, but for big sites with a lot of re-use it doesn't scale well with file size (or IE).
We still do things with the modular approach, but instead of doing the constants selector assignment we use classes in the HTML–keeping file size down and it's easier for back-end to help maintaining.
I know classes in the HTML gives you nightmares and stomach aches, but, get over it! 😉
I also partially agree with Nicole's approach to OOCSS. We only have two front-end developers (a colleague and myself, though we're only doing front-end development half of our time) so I can't say we work in a large team, but we do work on a large site.
The modular argument is clear to me and we've been doing this for a while now, but only in a way that the second class overrides existing properties of the initial class, never adds properties. The former is just a way to build exceptions whereas the latter is actual construction of new presentations. I highly discourage the latter, which is what Nicole recommends (I think) and I disagree with.
But sometimes using the modular (generic) or context (specific) approach for naming classes just does not work. We have a bunch of utility classes for grey text, small text, floating and whatnot for small styling, resulting in visual semantics being added in our HTML. The reason I allow but not encourage this is the simple fact that we want to keep the filesize of our stylesheet as small as possible. We simply cannot afford it to constantly add a new class for the same style simply because it's more semantic in name.
Because let's go back to the why of proper semantics. We've evangelized the myth (yes, I said that) of true seperation of content and presentation for so long, but reality has shown otherwise. In fact, in my experience, reality has shown that very rarely will you ever completely redo an interface without changing the HTML. Small design tweaks, sure, but never enough work to really take advantage of the seperation. So, in my job we need to go for whatever is the fastest and costs the least amount of maintenance.
Which is a topic I'd like to briefly mention as well: maintenance. There's a cost of maintenance not just for using visual semantics, but also for using proper semantics. If we practice our theory as well as we can, after several years and several redesigns of seperate areas of the site, we end up with a stylesheet full of classes of which we are unsure whether they are still used or not. The benefit of using very generic (thus to the point of visual semantics) classnames is that we only have one selector and even though it might not be used right now, it can be used wherever you want it to, because the class does not dictate the usage/context.
One clear distinction in experiences we must make is because of this maintenance aspect. A lot of us do client work where you hand of the project and probably won't ever see it come back. I myself need to deal with legacy, maintenance and future projects on a daily base. It definitely made me less pure in applying the theory 😉
@Kenneth, haha 🙂 True, the amount of selectors in the "parsed" code when using constants on a big site can get a bit out of hand.
But I would and could never slap classes all over the place since my framework only supports theming with CSS and JS – no HTML-changes allowed – so using classes such as left or right would get pretty limiting.
I do believe re-using code is primordial. Though, everyone uses his/her methods for building lay-outs. I will check it out, and come back with my remarks…
The only time I tend to use descriptive class names is when I want a class to float an image in an article to the right or to the left: I can't think of any other way to describe that.
[…] #CSS: Testing Object-Oriented CSS (OOCSS) for easier CSS development: [link to post] @integrateur_css […]
Absolutely, I can see where she's coming from, but I also believe there has to be some kind of middle-ground in regards to class names.
I mean, if a developer can't even understand that something should be to the right unless it has "right" in its name, I'm not sure you have the best developer for the job…
Absolutely, there are some exceptions, But, humbly, I would rather suggest "complementary", "secondary" or similar instead of "col2".
Interesting to hear about YAML!
I definitely recommend trying it out. After all, you can just change less semantic class names (like I did) – there aren't too many of them.
It looks interesting! However, personally, I prefer applying a number of class names with certain generic pre-defined styling to elements, whether it's being done dynamically on the server or not.
And humbly, if I don't misunderstand, you end up with a lot of repeated, thus redundant, code in your selectors?
Oh, absolutely. Some of Nicole's teaching,, with avoiding location-dependent styling etc, is quite good for reusability.
And never underestimate the importance of rapid development and code consistency. To make that work, not all class names can be great; I'm just arguing for less semantic and generic class names, but not ones that are outright poor in my eyes.
But sure, I agree: it's about context with that you are working on as well.
I, for one, believe it's absolutely ok to use the second class to add new presentation rules as well. 🙂
So, in my job we need to go for whatever is the fastest and costs the least amount of maintenance.
I definitely agree! It's about what you owe them as well as your customers. But we also have to bear in mind what we might sacrifice along the way to do that, and how we try to minimize the amount of sacrifice.
To me, using semantic class names isn't really about feeding the "myth" of having the same CSS for completely new HTML, but rather have class names that are at least semantic enough to convey any sort of meaning, and not being names of other elements etc.
Please do so, I think you will like it.
Oh, absolutely. I believe image floating, text aligning and such could have such a description. I believe it's not a good choice for column placement and such, though.
[…] Nyman heeft vorige week ook geschreven over zijn ervaringen met OOCSS. Door Bart, gepubliceerd op 23 november 2009 om 23:18, in Elders, Het web met de tags: CSS, […]
[…] 17: Testing Object-Oriented CSS (OOCSS) for easier CSS development […]