Preface
Object Oriented CSS (OOCSS) has recently made some buzz in the web industry and for very good reasons. It’s the kind of thing I go: why didn’t I think about this? As a CSS architect, I’m very enchanted to learn something new in the subject, all thanks to Nicole Sullivan at Yahoo.
It’s a great idea, well, just maybe
A lot of Nicole’s arguments were hammering around the fact that OOCSS would be faster. While it may be efficient to code OOCSS from a programmer’s perspective, it’s far from making your page load any faster. OOP concepts require you to separate classes into individual files so that the code becomes more manageable. However brilliant that is from a manageability perspective, it’s a nightmare plan for CSS speed. You don’t want to make your browser load every single little piece of CSS like that.
If your OOCSS class files are served from a single domain, the average browser will only handle 2 concurrent connections to that given domain, making your loading of CSS classes literally 2 at a time. This isn’t beneficial at all. Having multiple pieces would require your browser to wait for the other ones to finish before even sending a request for the rest, and that also makes a lot more HTTP requests, in other words, a lot of overhead.
PHP and other applications of course don’t have that problem since they request files that are stored on the server from the server, which just results in an insignificant increase in disk I/O. But the whole OOP concept remains slower however you see it. In software engineering, everything ends up being either a 1 or 0. The computer by itself cannot understand OOP, which means you have to add additional application logic to make it work, making things slower. The only reason OOP exists is to make it easier for programmers to develop complex applications, it has nothing to do with speed.
Easier to learn?
Apparently OOCSS is easier to learn. Yes, ok, it’s true that making it possible for a junior CSS developer to only handle smaller properties from different classes at first is a way to make CSS easier to work with. But it doesn’t make it easier to comprehend.
OOP concepts won’t help in any way at understanding the CSS box model, neither will they fix the differences between the various browsers. In fact, OOCSS just makes it more difficult to comprehend CSS because on top of that, you have to learn the Object Oriented concepts.
The only real easy part is what OO brings to anything; maintainability. You don’t have to dive into a super long page of CSS rules to modify something.
Cascading, not Object Oriented
Unfortunately for Sullivan, as she mentioned in her presentation, OOCSS is but a practice. CSS has never been Object Oriented, it’s a Cascading language. Using OO practices with CSS is a good idea, but it doesn’t really work. Let’s take a look at some examples:
<style type="text/css">
.block {
width:200px;
height:200px;
background-color:blue;
}
.redBlock {
width:400px;
background-color:red;
}
</style>
[...]
<div class="block redBlock"></div>
Ok, what do we have here. First off, you’ll notice there’s a lot of stuff missing, but just imagine there’s all the HTML headers and tags around it. So we have two classes and a div with both of those classes in its name. Yes, this is perfectly fine CSS practice.
With that, we would obtain a 400 by 200 pixels red square. The ability for the square to take one of the classes’ property and override it while still keeping its other properties intact is called Inheritance in OOP. Based on our HTML code, you would guess that redBlock inherits the properties of block. So how about we switch it like this:
<div class="redBlock block"></div>
The block would then take a blue color and a width of 200 px right? Well, this is where the problems start, it doesn’t. In fact, the order in which you specify the classes of the div has no importance whatsoever. In this scenario, we would still get the same red block with 400 px of width because the redBlock class is written after the block class in our CSS rules. This is called Cascading, which is where CSS takes its name: Cascading Style Sheets.
Most people who do CSS know the other aspect of Cascading which states that internal CSS overrides external, and in-line overrides internal. But very few know that it even extends directly into the declarations themselves, possibly because they’ve never used two classes in a single element at once, a very rare CSS practice as of now.
In real OOP however, there’s so such thing as cascading. By inventing some nice pieces of fictional CSS to define the inheritance, much in the way it’s done in real OOP languages, we can do the following:
<style type="text/css">
.block {
width:200px;
height:200px;
background-color:blue;
}
.redBlock {
extends:block;
width:400px;
background-color:red;
}
</style>
[...]
<div class="redBlock"></div>
In OOP, making a class “extend” another is literally telling it to inherit the properties of that class. In this scenario, we don’t even have to write the two classes inside the div because the CSS rules already define redBlock as inheriting (extending) the properties of the block class. We would obtain our famous red block. However, we didn’t say that block extended redBlock, so writing a div element with the class block would only use the block class’s properties, not the redBlock’s.
Unfortunately that CSS code is pure fiction. There’s no such construct in CSS and since it hasn’t been planned for CSS3, the whole idea remains largely a dream years away.
But do you really want this dream?
However brilliant this OO thing would be, its current implementation is nothing but a way of coding. Because of its functionality issues and overhead though, that way of coding CSS is nothing more than a gimmick.
In my opinion, it doesn’t bring in enough maintainability and functional benefits in its current state versus the overhead induced. Yes, Object Oriented practices do make it easier not to make scalability mistakes but a lot of Sullivan’s speech is just good practice, not OO. Every newbie in every field will make scalability mistakes no matter what the language.
I’m not sure if the current state of OOCSS solves anything.
