Oocss Separation of Container and Content

OOCSS Separation of Container and Content?

I think you are right in the sense that yes, in your specific example.. perhaps doing it your way would be easier. But then again, if you look at the first sentence in the OOCSS page:

How do you scale CSS for thousands of pages?

In that context.. the second principle makes perfect sense.. so using your same example (ie let's assume we implemented your solution).. let's say that a year down the road your company decides to create light grey buttons in the black footer having black text:

<!-- inside footer -->
<a class="button lightGrey">link</a>

in this case.. all the a tags will be white because they're covered by your cascading. So then we will have to go create another sytle just to undo what your solution did:

.footer a.button.lightGrey {
   color: #000;  /* huh? but i thought we did this before with a {color: #000;} ?*/
}

where as if we simply made a decision that all a tags by default are black (see last note):

a{ color: #000; }

then in the footer we will create a special type of link that are supposed to be white:

.footerLinks { color: #FFF }

then a year later some of the links are still white.. others within the greyLight button will be black:

<a class="button lightGrey">link</a>

then here we don't have to worry about undoing anything.. a tags have a default color.. and that's it. if 2 years later someone decides that the links inside the lightGrey buttons (anywhere on the site, not only withen the footer.. which is the whole point of OOCSS) should be red.. then this would be the OOCSS approach:

.redLink {
 color: red;
}

and the html will be

<a class="button lightGrey redLink">link</a>

in this case it won't matter if we take out the .lightGrey class, or we can have this code within or not within a footer .. it's all the same.. it results in more predictable and re-usable code.. which is OOCSS (I'm very glad that they're finally formalising this.. thanks a lot for the post btw).

One last note: To be pure OOCSS, one shouldn't change the default color of a ie a {color: #000;} is wrong!, it should be left to it's default color (which is blue).. whenever anyone wants to change that color.. then they must specify it ie

<a class="redLink">..</a>

so in this case it's more like the default a is the parent class.. and everything else subclasses it and overrides its default behaviour..

update - response to comments:

reputable site argument:

such initiatives are almost always driven by the community then adopted by reputable companies.. and even when they are adopted by larger companies it usually happens from the bottom up through enthusiastic developers who advocate for such change.. I for one was such an advocate when I was working in Amazon. And even when it's adopted.. it's usually at a small scale and not across all units in the org. it wouldn't even be a good idea for the Googles and the Amazons and the facebooks etc to enforce such a rule b/c there will always be a difference of opinion.. not to mention that such micromanagement would constrain the engineer's creativity.. there could be a guideline in a wiki for a team (ie we had one for the Amazon Kindle Touch app store) but to enforce that rule across 10,000 engineers working across the company wouldn't be practical nor desirable.

So in short if you see value in OOCSS, and start implementing on your site, and advocating it to your fellow web devs, and then it becomes a trend, that's when it eventually becomes an industry wide best practice and that's when you can expect to see it on facebook etc.

example:

take a look at this:

simple: http://jsfiddle.net/64sBg/

a bit more detailed: http://jsfiddle.net/64sBg/2/

without going too much detail (I'm sure you will see the pattern) you can see that the granularity in css descriptions allows for subtle changes without any redundancy in style definition. So notice the left arrow vs right arrow.. also the .red and .blue styles can be subsequently applied to tables etc..

also notice that there isn't a single cascading in my css.. so my styles can be completely independently applied (ie implementing the rule An object should look the same no matter where you put it)

lastly.. there is still use for cascading.. you can definitely use it in your jQuery selectors for example.. also cascading happens by default (ie without you having to explicitly set it in your css styles).. so if you take look at the css below.. you will notice that the font properties of body has cascaded down to all the buttons.

<a class="button blue dark">
    <div class=" arrowDownWhite rightArrow">Analytics</div>
</a>

<a class="button red dark">
    <div class=" arrowDownWhite leftArrow">Actions</div>
</a>

<a class="button grey light">
    <div class=" arrowDownRed leftArrow">options</div>
</a>

and css:

body 
{
    font-family: Trebuchet MS,Liberation Sans,DejaVu Sans,sans-serif;
    font-size: 15pt;
}

.button 
{
    padding: .5em 1em;
    display: inline-block;
    text-decoration: none;
}
.dark {
    color: white;
}

.light{
    color: #E40E62;
}
.blue
{
    background-color: #51C8E8;
}
.red 
{
    background-color: #E40E62;
}
.grey 
{
    background-color: #E0E0E0 ;
}
.arrowDownWhite
{
    background-image:url(http://s2.postimage.org/ywam7ec4l/small_Arrow_Down_White.png); 
    background-repeat:no-repeat;

}

.arrowDownRed 
{
    background-image:url(http://s2.postimage.org/je5743t2d/small_Arrow_Down_Red.png);
    background-repeat:no-repeat;
}

.leftArrow 
{
    padding-left: 1em;
    background-position: left center;   
}

.rightArrow
{
    padding-right: 1em;
    background-position: right center;  
}

OOCSS - only use class to do styling

Well, technically I think what they are referring to is that you should use classes instead of html element identifiers.

So perhaps doing something like:

<ul>
   <li class="li">a</li>
   <li class="li">b</li>
   <li class="li">b</li>
</ul>

And then just use your original styles like:

.li:nth-of-type(1) {}
.li:nth-of-type(2) {}
.li:nth-of-type(3) {}

In your case you're basically using classes as you would use an id. Classes are supposed to identify multiple elements.

using attribute selectors to style a web page

one problem with using attributes, is that they are invariably tied to a type of html element.. so in the above example, data-header can only be applied to divs.. if you want to apply the same style to a <p> tag for example.. you will have to write the style again:

p[data-header]

and since the only advantage that your'e talking about is that it requires less typing.. then that's a trivial advantage (ie we're not talking less processing or rendering time or increased maintainability etc)

I advise you to consider the principles of Object Oriented CSS (OOCCSS): where it has this key principle:

An object should look the same no matter where you put it. So instead of styling a specific h2 with .myObject h2 {...}, create and apply a class that describes the h2 in question, like h2 class="category".

this makes your css more reusable.. a common problem with poor css management is that you can easily end up with thousands of lines of css.. with much of it redundant.

For a concrete example of how OOCCSS can make css more reusable.. see this answer

important update: what i said above in terms of having a class more reusable than an attribute is not true (see discussion below).. so please ignore it.

now that being said.. i'd still steer away from using only attributes to style my html.. if for the only reason that you're using a css property for something different than what it was designed for

(in general it's not a good idea to be too clever with your code.. while it may save you time etc.. it can potentially confuse people who will use your code later.. always code with the attitude that other people from all over the world may get their hands on your code.. and so readability trumps less code etc.. esp when there is absolutely no other advantage such as processing time etc).

for example (and I'm saying this without even doing any research.. I'm just relying on my 10+ years exp using css).. if I see this in your code

<div data-header> 

I have no idea if this data-header is a unique selector or can be present else where.. but if I see this:

<div class="data-header"> 

then I can immediately conclude (without looking anywhere else in your code) that this is not a unique selector.. and that I can very well expect to see other elements in the same page or even other pages that have the same class applied to them..(ie as opposed to using <div id="data-header">.. which is then unique)

suppose I'm the javascript/jQuery guy and your'e simply the designer.. that's an unspoken piece of information you gave just by the virtue of you using CSS the way it's designed for. But then if start becoming all clever and using CSS properties your own way.. then that's recipe for trouble (see my question here and the comment I made under it.. It's just a bad idea to get something that means x for everybody and make it mean y just for you).

Object Oriented CSS: Catchy Buzz-phrase or Legitimate Design Approach?

I would say it's more of a catchy buzz-phrase for something already present in CSS. Of course, before we start talking about what is OO and what is not and how CSS is object-oriented, we would have to define what it actually is - which is something others have struggled with before and is subject to heated debates. But if we assume that the basic principles of OO are:

• Class
• Object
• Instance
• Method
• Message passing
• Inheritance
• Abstraction
• Encapsulation
• Polymorphism
• Decoupling

we can say, that Cascading Style Sheets are somewhat object-oriented, because they allow classes to be defined, instances/objects created (by assigning a class to an element), inheritance of classes (even multiple inheritance), abstraction (e.g. by defining styles for the plain elements) and polymorphism (by defining the same class name for different elements). Of course methods/message passing is not possible, because of the static nature of CSS.

So in general I would say its a valid approach to develop CSS in an object-oriented manner, but I would not really call it Object Oriented CSS, because at least to me, it is something deeply inherent to CSS. It would be somewhat like saying "I am doing Object Oriented Java..."

---

Related Topics