As with any object-based coding method, the purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.
As with any object-based coding method
CSS does not have objects though
and it’s code, but it’s not programming (getting closer and closer, but still not yet)
As SP said though, CSS doesn’t have objects, it may MANIPULATE objects by declaring properties FOR the DOM (Document Object Model) – but to even call this bloated nonsense “object oriented” is bullcookies. If anything it is the OPPOSITE of Object Oriented, since you’re NOT using the DOM’s inheritance and instead are inlining the properties on every element. If anything, this is PROCEDURAL CSS!
You have a DOM element, you give it a way to hook to it or use it’s inheritance, you declare properties for it with inheritance by type – that’s object oriented – taking a HTML element and slapping classes for each property on it – that’s not object oriented AT ALL. The exact opposite in fact!!! It’s almost like they threw the “object oriented” name on it to make it sound neat and trendy, instead of actually taking the time to think “what in blazes does this have to do with OOP?!?”
It’s certainly not faster since it results in more classes to be processed – it’s certainly not easier to maintain since you’re basically putting all your presentation back in the markup, defeating the entire point of even using CSS (and to an extent HTML) in the first place, and does NOT allow code re-use for the HTML since you declared your presentation in it. (meaning if you suddenly want to reskin you basically have to rewrite ALL the markup).
While I dislike their base code and most of their examples, see CSS Zen Garden for an example of what I’m talking about; you aren’t gonna do that with OOCSS – one markup for many layouts… Done by saying WHAT your content is, and then in the stylesheet saying what they look like – Separation of presentation from content – aka LETTING HTML AND CSS DO THE JOB THEY WERE DESIGNED FOR!
So… “faster and more efficient”? Not so much. The exact opposite in fact. IF you’re declaring presentation (and no, a div sandbag or wrapper doesn’t declare presentation, even if it’s used for it) in your markup, you’ve failed to grasp the concepts behind semantic markup, separation of presentation from content, and the entire POINT of HTML and CSS.
Wow, the more I think about this, the more I’m laughing at it… it’s NOT object oriented, it’s the EXACT opposite. No inheritance, no polymorphism, not actually leveraging the ACTUAL object model that’s present for CSS to work on…
That’s a riot.
That’s a riot.
I’m glad you’re having a good time 
It’s certainly not faster since it results in more classes to be processed
You’re kidding right? You’re arguing that we shouldn’t use multiple classes because of client-side performance?
It’s certainly not easier to maintain since you’re basically putting all your presentation back in the markup, defeating the entire point of even using CSS (and to an extent HTML) in the first place, and does NOT allow code re-use for the HTML since you declared your presentation in it. (meaning if you suddenly want to reskin you basically have to rewrite ALL the markup).
You have missed the point.
OOCSS is about re-using CSS, that is where maintenance headaches lie in larger apps (and small apps), the HTML can always be updated in one place as each component has a server-side wrapper.
I agree object oriented is a stupid name but the objects they are referring to are the structural components - these are what the classes represent. It’s not putting all of the presentation in the HTML, only what makes sense to re-use as components. Structure & skin are kept separate.
While I dislike their base code and most of their examples, see CSS Zen Garden for an example of what I’m talking about; you aren’t gonna do that with OOCSS – one markup for many layouts… Done by saying WHAT your content is, and then in the stylesheet saying what they look like – Separation of presentation from content – aka LETTING HTML AND CSS DO THE JOB THEY WERE DESIGNED FOR!
Sure you can. You can re-style each component without effecting everything else so you have a far greater level of control over the output.
Layout frameworks are a different story but we’ve already been there, I think grid layout being tied to the page level & content is ok.
It’s also not helpful to think of the page as a whole in these examples, OOCSS is for small re-usable components, not major elements like navigation, aside content etc…
So… “faster and more efficient”? Not so much. The exact opposite in fact. IF you’re declaring presentation (and no, a div sandbag or wrapper doesn’t declare presentation, even if it’s used for it) in your markup, you’ve failed to grasp the concepts behind semantic markup, separation of presentation from content, and the entire POINT of HTML and CSS.
We may have failed to grasp your point of HTML & CSS, but I use it to deliver content to users.
I want to be able to do that without rewriting stuff all over the place or duplicating effort, multiple classes work well.
and server side performance since it’s more to output, and bandwidth performance because it generally will use more bandwidth by saying classes on things that shouldn’t even NEED classes if you bother with semantics and inheritance…
Where CSS is about re-using style on markup WITHOUT saying it over and over again – AGAIN, “re-using CSS” in this manner is the EXACT same thing as forgettting CSS entirely and just using ALIGN, FONT, CENTER and all the other [b]deprecated[/]b nonsense… it’s the CSS equivalent of the “let’s use javascript to make a TARGET workalike because TARGET is deprecated” idiocy… bypassing WHY TARGET is deprecated outside FRAMESET doctypes. Again, see why I think STYLE should be obsoleted as a tag and throw a warning as an attribute… and to be frank, if you’re going to do this OOCSS garbage, you might as well not bother with a stylesheet and just use the style attribute on everything – since from a functionality standpoint it’s the same thing.
As opposed to not having to even THINK about going into the markup or the server side code and JUST edit the CSS? Sorry, that’s MORE work, not less. It REEKS of the philosophy of those who still pop up HTML 3.2 and slap 4 trannies or 5 lip-services on it.
When the classes only implement two properties on the DOM… when the classes in the markup are specific to certain appearance or layout elements… when the classes by their very nature ONLY server the purpose of specific presentational effects – uhm… NO. That’s not what they represent.
Putting ANY presentation there, with the rarest exceptions (like when the size actually represents data – charts or tag clouds for example) defeats the point of why HTML was created, the reason STRICT was implemented and we’ve been supposed to be using it, and needlessly bloats and over-complicates the page.
If you’re talking layout for structure, then it shouldn’t be separate – if you’re talking logical document structure, you’re putting layout in it so it’s not separate…
Which makes the examples pointless, come up with better examples… if not thinking about the page as a whole, one probably shouldn’t be writing for the web.
IF so then how does your grid example weigh into that since it’s being used for the entire layout? Also, small reusable components, particularly if re-used on the same page, would benefit more from semantic markup with single wrappers to say what it is than the “lets slap classes on EVERYTHING” idiocy.
Off Topic:
<aside>Also, “aside content” ??? – how often do you have real asides? <em>Not too often I’d guess</em>… but of course people seem to think “<i>aside</i>” means a sidebar now – <strong>having little to do the meaning of the word</strong> or what it’s supposed to be for in <b>HTML 5</b>… Always good for a laugh. Almost as laughable as the people who think B and I are deprecated or means the same thing as EM and STRONG…</aside>
How about TBL’s point? How about the entire REASON STRICT undid all the crapping all over the specification 3.2 did? Of course with HTML 5 taking a massive dump on it all over again…
Funny since the techniques you’ve been defending are all about rewriting stuff “all over the place” by basically turning back the clock to presentational markup – instead of saying once in the markup what it is (either with a single wrapper and then , then using inheritance to say once for many elements what it looks like in the CSS.
But again, about 80%+ of the markup out there I look at and go “why do you need this div, this div, this span, this tag, ANY of these classes… you’ve got a perfectly good ID why does EVERYTHING have a class on it when you have semantic tags…” – needlessly complex, convoluted and ultimately MORE work to deal with. Even the simplest of pages I’ll see DIV wrapping IMG for no reason, multiple classes for no reason… and encouraging people to slap even MORE classes on everything is NOT the answer.
I think that’s a lot of what our difference in opinion comes down to here – you’re concerned more about CSS redundancies than HTML ones… when CSS is cached making it’s redundancies less of an issue… where in CSS you can group selectors that get the same set of base properties WITHOUT bloating out the markup…
I often do think people who complain about ‘redundancies’ in their CSS are unaware of how to use multiple selectors…
I mean seriously, take a simple 100% width header/footer 100% min-height, constrained width content layout…
<div id="pageWrapper">
<div id="headerWrapper"><div id="header">
<h1>Test</h1>
<ul id="mainMenu">
<li>Dummy</li>
</ul>
</div></div>
<div id="content">
<h2>Test Content</h2>
<p>Some Content</p>
</div>
</div>
<div id="footerWrapper"><div id="footer">
Footer Content
</div></div>
#pageWrapper {
min-height:100%;
}
#headerWrapper,
#footerWrapper {
clear:both;
overflow:hidden; /* wrap floats */
width:100%; /* trip haslayout, wrap floats IE */
color:#FFF;
background:#00F;
}
#footerWrapper {
height:72px;
margin-top:-72px;
}
#header,
#content,
#footer {
min-width:752px;
max-width:68em;
width:95%;
margin:0 auto;
}
Is somehow inferior or harder to work with than:
<div class="minHeight">
<div class="wrapping darkbackground">
<div class="constrainWidth centered">
<h1 class="big red">Test</h1>
<ul class="menu centered">
<li class="menuItem">Dummy</li>
</ul>
</div>
</div>
<div class="constrainWidth centered">
<h2 class="big red">Test Content</h2>
<p class="padLeftMore">Some Content</p>
</div>
</div>
<div class="wrapping darkbackground clearing rideUpFooter">
<div class="constrainWidth centered">
Footer Content
</div>
</div>
.fullMinHeight {
min-height:100%;
}
.wrapping {
overflow:hidden; /* wrap floats */
width:100%; /* trip haslayout, wrap floats IE */
}
.darkBackground {
color:#FFF;
background:#00F;
}
.clearing {
clear:both;
}
.constrainWidth {
min-width:752px;
max-width:68em;
width:95%;
}
.centered {
margin:0 auto;
}
.rideUpFooter {
height:72px;
margin-top:-72px;
}
Since that’s BASICALLY the difference we’re talking about in OOCSS vs. Non. In non, I suddenly want to change #contents behavior I just override it in the cascade, or I move Content out of the width declaration area – I want to do that the OOCSS way, I’m digging into BOTH the CSS and the HTML, for no reason.
Apart from throwing multiple classes at things that probably either just need one or none, what’s even the POINT?
Then take something simple – like say you wanted rounded bottoms on #header and rounded tops on #footer – the non–OOCSS way you go ok,
#header { border-radius: 0 0 1em 1em; }
#footer { border-radius:1em 1em 0 0; }
While your OOCSStards would make new classes for each border type, and go into the markup and add it instead of just leveraging the already present and easy to use ID… and if that’s not the dumbest thing you’ve ever heard…