An Introduction To Object Oriented CSS (OOCSS)

Advertisement

Have you ever heard the phrase “Content is King”? Being a Web developer, and therefore having a job that’s often linked to content creation, it’s likely you have. It’s a fairly overused but true statement about what draws visitors to a site.

From a Web developer’s perspective, however, some may argue that speed is king1. More and more, I’m starting to favour that stance. In recent years many experienced front-end engineers have offered their suggestions2 on how we can improve the user experience by means of some performance best3 practices4.

Unfortunately, CSS seems to get somewhat overlooked in this area while many developers (for good reason) focus largely on JavaScript performance and other areas5.

In this post, I’ll deal with this often overlooked area by introducing you to the concept of object oriented CSS and how it can help improve both the performance and maintainability of your Web pages.

The Principles Of OOCSS

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.

OOCSS

As described on the OOCSS GitHub repo’s Wiki page6, OOCSS is based on two main principles.

Separation of Structure From Skin

Almost every element on a styled Web page has different visual features (i.e. “skins”) that are repeated in different contexts. Think of a website’s branding — the colors, subtle uses of gradients, or visible borders. On the other hand, other generally invisible features (i.e. “structure”) are likewise repeated.

When these different features are abstracted into class-based modules, they become reusable and can be applied to any element and have the same basic result. Let’s compare some before and after code so you can see what I’m talking about.

Before applying OOCSS principles, you might have CSS that looks like this:

#button {
	width: 200px;
	height: 50px;
	padding: 10px;
	border: solid 1px #ccc;
	background: linear-gradient(#ccc, #222);
	box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#box {
	width: 400px;
	overflow: hidden;
	border: solid 1px #ccc;
	background: linear-gradient(#ccc, #222);
	box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#widget {
	width: 500px;
	min-height: 200px;
	overflow: auto;
	border: solid 1px #ccc;
	background: linear-gradient(#ccc, #222);
	box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

The three elements above have styles that are unique to each, and they’re applied with the non-reusable ID selector to define the styles. But they also have a number of styles in common. The common styles might exist for branding purposes or consistency of design.

With a little bit of planning and forethought, we can abstract the common styles so the CSS would end up instead like this:

.button {
	width: 200px;
	height: 50px;
}

.box {
	width: 400px;
	overflow: hidden;
}

.widget {
	width: 500px;
	min-height: 200px;
	overflow: auto;
}

.skin {
	border: solid 1px #ccc;
	background: linear-gradient(#ccc, #222);
	box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

Now all the elements are using classes, the common styles are combined into a reusable “skin” and nothing is unnecessarily repeated. We just need to apply the “skin” class to all the elements and the result will be the same as what the first example would produce, except with less code and a possiblity for further reuse.

Separation of Containers and Content

The second principle described on the OOCSS GitHub wiki page is the separation of containers from their content. To illustrate why this is important, take the following CSS:

#sidebar h3 {
	font-family: Arial, Helvetica, sans-serif;
	font-size: .8em;
	line-height: 1;
	color: #777;
	text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

These styles will apply to any third-level headings that are children of the #sidebar element. But what if we want to apply the exact same styles to third-level headings that appear in the footer, with the exception of a different font size and a modified text shadow?

Then we would need to do something like this:

#sidebar h3, #footer h3 {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 2em;
	line-height: 1;
	color: #777;
	text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

#footer h3 {
	font-size: 1.5em;
	text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

Or we might end up with something worse:

#sidebar h3 {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 2em;
	line-height: 1;
	color: #777;
	text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

/* other styles here.... */

#footer h3 {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 1.5em;
	line-height: 1;
	color: #777;
	text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

Now we’re unnecessarily duplicating styles, and might not realize it (or simply don’t care). With OOCSS, we’re encouraged to give more forethought to what is common among different elements, then separate those common features into modules, or objects, that can be reused anywhere.

The styles that are declared using the descendant selector in those above examples are not reusable, because they are dependent on a particular container (in this case either the sidebar or the footer).

When we use OOCSS’s class-based module building, we ensure that our styles are not dependent on any containing element. This means they can then be reused anywhere in the document, regardless of structural context.

A Real-World Example

To further illustrate how OOCSS can be used, I’ll use something similar to what I did on my site’s recent redesign7. After coding the inner header element on my site, I realized that the basic structural styles for the inside of the header could be reused on other elements on the page.

So here’s something along the lines of what I had when I started styling my header:

.header-inside {
	width: 980px;
	height: 260px;
	padding: 20px;
	margin: 0 auto;
	position: relative;
	overflow: hidden;
}

A few of the styles listed here are unique to the .header-inside element. But the rest can form a module that I can reuse. So I can abstract the structural styles into their own reusable class. Here’s the result:

.globalwidth {
	width: 980px;
	margin: 0 auto;
	position: relative;
	padding-left: 20px;
	padding-right: 20px;
	overflow: hidden;
}

.header-inside {
	padding-top: 20px;
	padding-bottom: 20px;
	height: 260px;
}

The styles belonging to the .globalwidth class cover the following:

  • A fixed width
  • Centering using margin: auto
  • Relative positioning to create a positioning context for child elements
  • Left and right padding of 20px
  • Overflow set to “hidden” for clearfixing

Now we’re free to use these styles on any elements that require these same characteristics by simply adding that class to the desired element — without writing a single extra line of CSS.

For my site, I reused these structural styles on the primary content element and the inner footer element. Depending on the design, these styles could also apply to a horizontal navigation element that might appear between the header and the content, or any other element that has a fixed-width and needs to be centered on the page.

After adding the “globalwidth” styles to these elements, the markup would look something like this:

<header>
	<div class="header-inside globalwidth">
	</div>
</header>

<div class="main globalwidth">
</div>

<footer>
	<div class="footer-inside globalwidth">
	</div>
</footer>

Some may feel that this type of styles abstraction clutters the HTML and goes against the principle of separating markup from presentation.

But putting aside any debates about how this might affect the markup, no one can question that this abstraction has now made it easier to track down and modify the common styles that are used to structure these three elements.

The Media Object

One of the pioneers of the OOCSS movement is Nicole Sullivan158. She’s created a reusable module called the media object9 which, as she explains, can save hundreds of lines of code10.

OOCSS

The media object is a great example of the power of OOCSS because it can contain a media element of any size with content to its right. Although many of the styles that apply to the content inside of it — and even the size of the media element itself — could change, the media object itself has common base styles that help avoid needless repetition.

The Benefits Of OOCSS

I’ve already alluded to some of the benefits of OOCSS. Here I’ll expand on these.

Faster Websites

The performance benefits of OOCSS should be fairly clear. If you have fewer styles that are repeated in your CSS, then this will lead to smaller file sizes and thus faster downloading of those resources.

It’s true that markup will be more cluttered and thus create larger HTML files. But in many cases the amount of loss in markup performance will be greatly surpassed by the amount of gain in stylesheet performance.

Another concept to keep in mind is something that the OOCSS wiki refers to as performance freebies. This refers to the fact that every time you reuse something in your CSS, you’re essentially creating new styled elements with zero lines of CSS code. For large, high-traffic projects, these “freebies” could be a crucial performance gain11.

Maintainable Stylesheets

With OOCSS, instead of a constantly growing stylesheet full of specificity wars, you’ll have an easy to maintain set of modules where the natural cascade plays an important role.

When making additions to an existing site, you won’t be adding new styles to the bottom of your stylesheet without regard for what came before. Instead you’ll be reusing existing styles and extending your styles based on existing rule sets.

With this type of forethought, it’s possible to create entire pages while coding very little CSS. Any existing CSS modules can serve as a basis for all new pages, and any new CSS will be minimal. In some cases you might even be able to create a new fully-styled page without coding a single line of CSS.

These maintainability benefits also extend to the robustness of your stylesheets. Because the styles are modular, pages built on OOCSS will be less likely to break when a new developer starts to use the stylesheet.

Points Worth Noting

OOCSS has created a great deal of discussion in the community, raising some controversies. Here I’ll try to dispel a couple of common misconceptions.

You Can Still Use IDs

If you decide to work exclusively in an OOCSS manner, then your styles will be based largely on CSS classes, and you won’t be styling elements using the ID selector.

Because of this, many have falsely claimed that OOCSS encourages dropping the use of IDs completely. But this is not true.

The rule to avoid IDs is, more specifically, don’t use IDs in selectors. So it’s perfectly acceptable to use OOCSS principles (and thus avoid styling using the ID selector) while using IDs in your HTML for JavaScript hooks and fragment identifiers.

Of course, you may have a situation where you already have an ID applied to an element that you know is unique to the page. So, you can save a few bytes by avoiding adding a class to that element and instead style it using an ID selector. But even in this instance, it’s much safer to rely on a class to ensure you don’t run into specificity problems in the future.

Dealing With Smaller Projects

For smaller sites and apps, you could certainly make the case that OOCSS would be overkill. So don’t take this article as an advocacy for OOCSS in all circumstances — it will vary depending on the project.

Nonetheless, I think it’s a good idea, at the very least, to start thinking in terms of OOCSS in all your projects. Once you get the hang of it, I’m sure you’ll find it much easier to get it working on bigger projects where the benefits would be more noticeable and relevant.

Some Guidelines For Implementation

Getting started working with OOCSS could take time. I’m still working on it, so I don’t claim to have all the answers and experience in this area.

But here are some things you might want to start doing to help you get into an OOCSS mode of thinking:

  • Avoid the descendent selector (i.e. don’t use .sidebar h3)
  • Avoid IDs as styling hooks
  • Avoid attaching classes to elements in your stylesheet (i.e. don’t do div.header or h1.title)
  • Except in some rare cases, avoid using !important
  • Use CSS Lint12 to check your CSS (and know that it has options and method to its madness13)
  • Use CSS grids14

There will obviously be times when some of these rules will be broken, but overall, these are good habits to develop and will lead to stylesheets that are smaller and easier to maintain.

Follow Nicole Sullivan’s Work

If you want to continue learning about OOCSS, the most important person in the industry to keep up with is Nicole Sullivan158.

In addition to posting articles regularly on OOCSS on her blog, Nicole has done a number of presentations with accompanying slideshows. Below are some that you might want to check out:

Conclusion

Many people fear the OOCSS ideology because it seems to go against many of the so-called “best practices” we’ve learned. But once the long-term benefits of using OOCSS are understood, I’m sure many developers will become converts.

Overall I think OOCSS has a bright future in CSS development, and it’s a concept that all developers should start incorporating into their projects — at least on some level — to help create Web pages that are faster, more efficient, and easier to maintain.

(il)

Footnotes

  1. 1 http://www.stevesouders.com/blog/2009/10/06/business-impact-of-high-performance/
  2. 2 http://www.stevesouders.com/blog/
  3. 3 http://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309
  4. 4 http://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/0596522304/
  5. 5 http://developer.yahoo.com/performance/rules.html
  6. 6 https://github.com/stubbornella/oocss/wiki
  7. 7 http://www.impressivewebs.com/rolled-new-design/
  8. 8 http://www.stubbornella.org/
  9. 9 https://github.com/stubbornella/oocss/wiki/Content
  10. 10 http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/
  11. 11 http://www.svennerberg.com/2008/12/page-load-times-vs-conversion-rates/
  12. 12 http://csslint.net/
  13. 13 https://github.com/stubbornella/csslint/wiki/Rules
  14. 14 http://www.stubbornella.org/content/2011/01/22/grids-improve-site-performance/
  15. 15 http://www.stubbornella.org/
  16. 16 http://www.slideshare.net/stubbornella/object-oriented-css
  17. 17 http://developer.yahoo.com/blogs/ydn/posts/2009/03/website_and_webapp_performance/
  18. 18 http://www.slideshare.net/stubbornella/our-best-practices-are-killing-us
  19. 19 http://www.slideshare.net/stubbornella/css-bloat

↑ Back to top Tweet itShare on Facebook

Louis Lazaris is a freelance web developer and author based in Toronto, Canada. He blogs about front-end code on Impressive Webs and curates Web Tools Weekly, a weekly newsletter for front-end developers.

Advertisement
  1. 1

    Ramesh Vishwakarma

    December 14, 2011 4:33 am

    I think this is the really a great way to implement the css. In this way we can reduce the size of our css file.

    0
  2. 52

    Woah.

    This isn’t object oriented. It’s just Cascading. That’s what CSS does.

    4
  3. 103

    What would be really cool is if we can include base classes in the derived classes directly in the css so that we don’t need to explicitly include the base class in our elements. For example, if button, box, and widget made a reference to skin in css then we don’t need to include skin in our elements.

    1
  4. 154

    Thank you for this article.

    Like Will said: This is cascading! :)

    Cascading or OOCSS like you named it, is a normal approach when you CSS skills are improving.

    There was always talking about to no repeat or duplicate same styling, this is how you need to write your CSS stylings :)

    0
  5. 205

    very good!

    0
  6. 256

    Hey, Louis! Thank you very much for the article. I allowed myself to translate it into Russian and publish in my blog . In our language there is no information about OOCSS, but we have so many good developers, who should be interested in this topic.
    Thank you.

    0
  7. 307

    Again, I see trends leaning towards presentational markup. What is going on? All these grids that people are using use presentational markup, this article also advocates its use… I am confused.

    0
    • 358

      If you can give me a good, practical reason why so-called “presentational markup” is bad, then you may have a point.

      But unfortunately, like many trends we’ve seen in web design over the years, this aversion to “presentational” styles has no practical problem-solving basis. It’s one of those “it looks better, but there’s no other reason for it” kind of things.

      0
  8. 409

    Louis, I’d never heard of (nor considered) the concept of object orientation in CSS. Thank you for challenging me with and explaining a new (for me) concept!

    0
  9. 460

    It’s easy to get lost with classes in OOCSS but it’s important to remember that we still so very much need IDs for things like jump menus (accessibility) and javascript performance.

    0
  10. 511

    I have been following the OOCSS project for the past 2 years, and I have seen many of the same arguments here as I see on the OOCSS Google group. Some of them very valid, others not so valid and just pointless. Just reading thru the comments on this post show we still have a long way to go as a development community. OOCSS is just one option out there, good or bad, someone is trying to make a difference… I see the true value in that. Frameworks (or in this case method) may (or may not) add a little code bloat, but they also add structure, standards (loose) and a system of problem solving.

    Lets keep this evolving, let’s stop with the OO bashing (so maybe it was a poor choice in naming), the semantic vs separation, and don’t be closed minded because it goes against your standards or best practices. You don’t like it, don’t use it, have a better idea, start a project on GitHub and show it to us.

    Louis, great write up… been waiting to see more people talk about OOCSS.

    1
  11. 562

    Exactly right – OO inheritance is perfect for CSS layouts. I’ve started doing this myself, and I have seen other CSS code on this line, glad to be on the wave, it means I am going in the right direction!

    0
  12. 613

    I certainly like the idea, but somehow i feel ike this should be implemented in the clean up phase after the site is coded, or only on items you are certain will not change,
    because if you need to change something later you may not be able to do it in css alone, you might very well find yourself doing a search and replace to update several html files if you need to an update later on, but i can see a lot of benefit to using this technique

    0
    • 664

      @Michael Hall

      We can use OOCSS in cases of CMSes like Drupal can change the HTML structure easily later. In some special cases, when we can do that, use LessCSS or SASS to take the benefits of OOCSS.

      0
  13. 715

    OOCSS is a very good idea to store CSS snippets, but be careful when applying it in the real world because it makes website unskinable. But note that we can fix the problems by using SASS, LessCSS or using a CMS which can change HTML-classes.

    0
  14. 766

    Don’t ever think that object oriented programming is an actual thing and don’t EVER use it. CSS means cascading style sheets. Apply the most common styles to the most general areas and override the more specific areas where necessary. Any experienced web developer knows that the entire concept of OOCSS is ridiculous. The term object oriented doesn’t even make sense in the context of CSS.

    I wouldn’t worry about the size of your CSS file either as this is only one http request. On the other hand I’ve seen a bunch of projects where developers try to do this OOCSS stuff and wind up with a layout.css, text.css, skin.css, main.css, etc… This is a major performance hit to include that many more http requests.

    Also everything you mention in the “Some Guidelines For Implementation” section goes completely against what CSS was designed to do. It’s just so wrong I don’t even know where to begin…

    0
    • 817

      It’s ridiculous to say that such advice “goes against what CSS was designed to do”. CSS has different features to make it flexible, but that doesn’t mean we have to use all of those features at all times, regardless of performance and maintenance.

      OOCSS helps developers focus on “the good parts” of CSS, just like best practices in JavaScript (like avoiding global variables, avoiding eval, etc) help developers focus on “the good parts” of JavaScript.

      0
  15. 868

    I can definitely see this as useful especially on big projects and team-based design, but i don’t like the idea of adding so many classes to my html, even though it does work well for targetting in wordpress.

    generally i declare ids and classes witht he same attribute using commas, like this:

    #header, #pri-nav, #footer {
    width: 900px;
    padding: 1em;
    }

    and then if i need to ‘skin’ one of those similarly styled items:

    #footer {
    color: #fff;
    background-color: #999;
    }

    so i can still group similar items in my css file, and still ‘skin’
    my footer with white text on a dark background, without adding
    so many classes to my html.

    i think both ways work fine, but i’m concerned with doing a major
    update later that i’d have to find-and-replace in multiple html files
    instead of just updating one css file, but i do like the approach
    as it would keep my css DRY.

    = )

    0
  16. 919

    Presentation information MUST be kept completely separate from content if you’re using a single content base (e.g., XML) to underly multiple delivery options (HTML, PDF, SMS), otherwise you’ll have to edit multiple places when the base content is updated. Forget about providing users with the ability to change the presentation to fit their learning styles.

    Also, it would seem that the extensive use of “multiple class assignments” on single elements would, if the site was big enough, eventually cause just as much of a delay as a bigger stylesheet.

    Do multiple people work on the site? How do you ensure that they code multiple class assignments the same? and would look the same, but have fun with the find/replace if someone later on decides that this class should be used for all subheaders in the site, or that “globalwidth” is no longer appropriate.

    0
  17. 970

    Al tough I like the idea behind OOCSS (reusing small code blocks) but CSS simply is *not* object oriented and should never be thought of as such.

    Object oriented design patterns are architectural concepts used to solve common problems in software development. CSS is a query language with a set of decoration notations and nothing more.

    Giles Bowkett asks a valid question: “Object-oriented CSS would be awesome, but faces tough questions. Which is the fundamental unit of CSS: a rule? a cohesive visual element on the page? the DOM tree a rule applies to?”

    0
  18. 1021

    Great !!! CSS maintainability becomes serious issue and quickly it becomes spaghetti code. In rails sass and scss also give some organization to css which makes it more modular if not completely object oriented.

    0
  19. 1072

    Uriah Rittenhouse

    January 2, 2012 12:12 am

    I’m with you on the importance of separating skin from structure and so on. You needn’t slave over too many behemoth sites to learn the value in that lesson good and well.

    0
  20. 1123

    I get the idea of OOCSS, but I think it might be problematic when using media queries. For example if I create a seperate class for floating elements (like .fl {float:left}) and use it for my sidebar instead of just floating the sidebar in it’s own seperate class (or ID), I end up reseting the .fl class every time I don’t want the side bar to float.

    Generaly I think we should be quite careful when implementing OOCSS, otherwise we may end up creationg seperate class for every declaration and dozen of clasess declared inside every single tag, like:

    Something

    0
  21. 1174

    Gunnar Bittersmann

    January 11, 2012 1:45 pm

    Why haven’t I read the word “responsive” in neither article nor comments yet?

    You just can’t build a responsive web design with this OOCSS approach. Modern web design calls for responsiveness since users browse the Web on a variety of devices: smartphones, tablets, laptops, desktops, TV sets, …

    You need different styles for different devices – applied to the same mark-up. You just can’t do that with styling coded into the HTML.

    You might have argued that OOCSS was useful five years ago (I have made my point that it has never been) but it does not have any use in today’s modern web design.

    0
  22. 1225

    Nice article. Overall is fine. Just have one comment.
    Regarding this one:
    Overflow set to “hidden” for clearfixing – it’s not a good practice to make all of your div or content holder to make overflow hidden, because sometimes there’s a layout that has image outside the div/s. If you set the div to ‘overflow:hidden;’ that image will not be seen. In order to clear the float, there are two ways. First, is to have overflow hidden on the container. Second, is to have clear both after the float-left.
    Example:
    1. overflow hidden on the container
    -div class”container”-
    -div class=”float”-
    Content here
    -div-
    -div-

    2. clear both after the float-left
    -div class”container”-
    -div class=”float”-
    Content here
    -br class=’clear’-
    -div-
    -div-

    Hope this make sense. God bless always!

    Best regards,
    alfieindesigns =.)

    0
  23. 1327

    That’s just awful. Seriously, you people try so hard to be one step forward of everyone and come up with these ridiculous names. There isn’t and never will be such thing as object-oriented CSS. You’re not a better and definitely not a cooler developer if you come up with ridiculous names to describe your work. It just shows you’re trying too hard. Sure, you can call a potato Ferrari, but it’s still going to be a potato. This article has got some good written css, but that’s all. In fact, if you are a good front-end developer, you probably have been coding css like this for ages. OOCSS, oh Lord, have mercy!

    0
    • 1378

      The undermining of the name is uncalled for. If you don’t like to label your methodology then don’t, but no need to get angry at others for doing it. There is nothing wrong with naming an unique approach to certain things i.e. sprite, sliding door, etc. No one should feel threatened by this as it is not an ‘absolute’ way. Take what you feel works and leave back what you feel doesn’t. If you feel your own approach to organizing/using css is helpful enough to the community by all means share as well (i.e. http://smacss.com/ is another detailed approach) I assure you most people, at least I, won’t be offended :)

      I believe OOCSS can be semantic, but it’s rather a new concept to the public and we’re all not used to it so it might take some time to evolve. Semantic at its core should just make the code readable to human and I think sometimes people become too obsessed with it. I think we can still use the sub class methodology while still maintaining semantics.

      For example an anchor tag with the class “button callout” provides as much semantic and more flexibility compared to an anchor tag with the class “sign-up” I feel.

      0
    • 1429

      Raquel Elle Bell

      April 6, 2012 9:36 am

      @John I think you would have to understand object oriented development to understand this concept.. The name itself is a perfect description for this style of designing and works extremely well in terms of rapid design.

      0
  24. 1480

    Hi there,
    really liked your post, thanks! :) I’m not sure if I got it. You intruduce OOCSS as if it would be a new and useful idea.

    What about SCSS? SCSS is using the same ideas like OOCSS just a lot more. You may use mixed selectors, mathematical methods in your CSS, and it keeps your code really DRY. So it’s a quite old idea and works fine.

    There’s Compass which is built on the top of SCSS (like LessCSS what @Sebastian mentioned), as soon as you write your OO-like CSS code it translates it with all necessary browser-hacks in a sec. No need to study other’s CSS grid’s name or anything else, just coding fast like hell.

    Further more there are a ton of CSS frameworks which are working much better and faster then OOCSS. For example here’s another post on SmashingMagazine about FoundationCSS, or here’s BluePrint.

    May I ask if you have any convincing reason why I should study OOCSS if SCSS is much faster and better? Or why OOCSS is better then _any_ CSS framework? Liked your post but I’m not sure if I really need OOCSS, please convince me!:) Thanks,
    YogiZoli

    0
    • 1531

      I’m feeling quite the same way, have been using Sass (.scss) for quite some time. However, I find some more abstract ideas in this article really important and useful, and very applicable when writing CSS, OOCSS or Sass – due to the ideology more than the actual tool.

      I find the idea of completely modularizing your CSS as opposed to messing around with too specific selectors etc. really sensible. But this is all much more fun and interesting when working with Sass, where you really, really can go that completely DRY approach everyone is secretly dreaming about.

      Thanks for a good article, OOCSS seems not to be for me but was still an interesting read.

      0
    • 1582

      OOCSS and SCSS are not the same thing, so its not matter of which to learn. SCSS does keep code DRY when your writing it, but once its compiled all the CSS rules in your SCSS mixins and variables etcs are expanded completely. This concept of OOCSS aims ( successfully?…debatable ) to use less CSS code in your stylesheet ( the one the browser actually sees ), but more in your markup

      0
  25. 1633

    I don’t understand, how should we be styling descendants then? (SEPARATION OF CONTAINERS AND CONTENT).

    0
    • 1684

      Heres an example from the OOCSS github repo that explains how to style a number of examples…

      “Essentially, this means “rarely use location-dependent styles”. An object should look the same no matter where you put it. So instead of styling a specific with .myObject h2 {…}, create and apply a class that describes the in question, like .

      This gives you the assurance that: (1) all unclassed s will look the same; (2) all elements with the category class (called a mixin) will look the same; and 3) you won’t need to create an override style for the case when you actually do want .myObject h2 to look like the normal “

      0
  26. 1735

    Great Article!

    0
  27. 1786

    Awesome Article! thanks!

    0
  28. 1837

    Raquel Elle Bell

    April 6, 2012 9:32 am

    I code in the same way. I call it CSS Light – It allows me to create individual classes that I string together to create more robust styles. This allows me to create one style sheet and re-use it over and over because it is not specific to one application. I have also gone a step further and created a naming system for my images and backgrounds. Because every project is going to have a different look I simply change out the image files but do not have to change out my css. It looks like this. –div class=”c12 bg0 r5 fl”/div– this means that the container is 12 columns wide, background, 5px round corners and floats left. I could easily change this up or add to it depending on what the design requires. In addition designing and developing this way enables me to create consistent layouts. The point of this type of development is rapid, re-usable code that fits together to perform complex operations. It is the same methodology utilized by our modular asp .net system in creating small building block applications that we can fit together to perform complex operations. Taking this methodology to the design level has increased our productivity and allowed us to not only rapidly develop our systems but our GUI’s as well. It also gives us a standard lexicon from design to development and a standard methodology that both designer and developer can understand…. I think the reason why many designers do not understand the effectiveness of this methodology is due to the fact that they are not on the dynamic side of development in terms of business logic, data layers, creating libraries, controls and enterprise level application development. I think you have to understand that first before you can really grasp this concept.

    0
  29. 1888

    Simon Fletcher

    May 15, 2012 8:29 am

    This is a great article on how to write CSS properly. I think that it has object orientated routes in that it has reusable code however Its not like other programming languages like PHP and especially Java. This is just the proper way that CSS should be written.

    0
  30. 1939

    This is just great. This kind of Technic is really going to do a great deal in a gigantic project. Precisely i guess it will also a good strategy of doing a best practice of css coding. I have been looking for kind of idea that will help me to make betterment of my coding practice. I think not only in a big project but also the practice of making module can be use in a tiny project also. whatever may be it’s depend on what kind of project you are handling.

    0
  31. 1990

    I have read so many articles about the blogger lovers however this article is truly a good post, keep it up.

    0
  32. 2041

    Everyone loves what you guys are usually up too. This kind of clever work and reporting! Keep up the awesome works guys I’ve added you guys to my blogroll.

    0
  33. 2092

    With normal “old school” css, I can do CSS3 animations (color, size, opacity…etc) by adding one extra class to and element, with your theory, it will be adding multiple classes to an element which makes it harder to write JS code and the performance will be poorer.

    0
  34. 2143

    A week ago, I released a feature rich CSS framework with a fully OOCSS architecture. It is optimised for performance, cross-browser support as well as modularity.

    Due to the OOCSS architecture, the framework’s footprint is tiny. Depending on which build you use, the CSS of the framework varies from 2,5Kb to 10Kb minified and gzipped.

    You can check it out at http://jslegers.github.com/cascadeframework/ .

    1
  35. 2194

    Like many things, it seems to me to be a question of balance, and situation-specific needs. In general, the approach I find myself using is SMACSS-like (though it deviates considerably from Snook’s recommendations).

    I think of styles in terms of base classes (defaults, resets), layout (semantically meaningful containers that constrain content), modules (self-contained groups, analogous semantically to the purpose of an article tag in HTML–it can be removed and used elsewhere without compromising its meaning), themes (skins–presentational considerations), and states (variations in presentation, occasionally structure) based on a particular state of the page (e.g., an error message, menu visibility, progress bar activity).

    Then, in my HTML markup, I am comfortable having a list of classes that refer to one or two of each of these as needed. Typically, in a module, I may have two classes that refer to the module structure itself — one true for all modules and the other for this one in particular, then one or two presentational classes (say, one describing content positioning, the other effects like rounded corners), then one for state (visible/hidden, has focus, etc.).

    If I have more than about four or five classes applied to any one element, and more than two for any one aspect of CSS, then it usually means I’ve overly refactored my styles. This may be appropriate for huge, constantly changing, “you never know” sites where you want to be free to apply anything to anything and you’re dealing with many subtle variations on existing style. But in general, at least for me, this is overkill.

    Most of the time, this approach allows easy modular reuse (independent of layout and presentation), and gives me or other developers the freedom to augment or modify my HTML markup to create style variations, leave the HTML alone and use overrides for the variations, or make changes to the CSS declarations affecting everywhere the class is applied.

    As far as bloat and performance, my CSS files end up not as small as they could be, but my HTML stays a little smaller as well. This is purely anecdotal, but I suspect it nets out to about the same as having tighter HTML and more bloated CSS, and vice-versa.

    One could argue this middle ground is the worst option, diluting the benefits of OOCSS and a classical approach at the same time, but in my experience it is a workable happy medium, where options are kept open without much being sacrificed. I’m curious whether other people approach it in a similar way. I’d also be curious whether there’s some key that I’m missing that would convince me to go all OOCSS or all SMACSS or something else–I’m open to improving my approach.

    0
  36. 2245

    The main thing that would have steered me away from OOCSS in the past is the lack of separation between style and markup. If you have a classes like `globalwidth` or `skin` attached as HTML classes in your markup, that reflects how the elements look, not what they are. That sort of class is not really ‘meaningful’ with regards to what the element is (I reject the use of the word ‘semantic’). If, in future, you decide to redesign your page, you will need to go through your html file (or even worse, hundreds of javascript files) and remove all references to any of these classes, and then go through it all again and attach all the new classes.

    However, the relatively recent introduction of CSS preprocessors has completely changed all that. Now, you can effectively attach this sort of class directly in the stylesheet and not have to worry about having to modifying markup in the future. This keeps styling in the stylesheets and layout in the markup.

    Since this is a top result whenever someone googles ‘OOCSS’, I suggest that you update this page to make reference to that fact.

    2
  37. 2296

    Isn’t this the normal way that CSS is supposed to to be used in the first place?
    I really don’t understand those why author tries to pretend that he invented something new…

    0
  38. 2347

    This is great article and I believe that this will have a great contribution to web development in the future. While reading this article, I felt like listening to the speaker of YUI-CSS reset from Yahoo. It has the same content and idea about reusing codes. Thank you for posting this sir.

    1

↑ Back to top