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 best3practices4.

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.

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:

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:

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.

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?

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.

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:

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:

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:

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 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 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.

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.

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.

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.

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.

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.

Related Articles

Jurij Burkanov

Though it’s being an interesting attempt in order to fight bloated and unmaintainable CSS, I don’t think OOCSS is a ready-to-use solution. It demands much to complicated naming convention and raises a need for an enterprise-grade assets management system – because after a half-year development you’re going to be exactly as lost in multiple styles and their derivations as before.

2

2

Alex

RussellUresti

One of the reasons I don’t get behind methodologies like OOCSS or many CSS frameworks is because they’ve completely abandoned the thought of semantics in markup. Your markup, which includes your class names, is meant to describe the content without thought to the how the page will be styled. By littering your markup with classes like “globalwidth” or “skin” that lack any semantic meaning, you’re just cluttering your markup.

I do find that there are occasions where using this approach is a viable solution (for example, I used it when creating rapid prototypes for testing that would never actually be released as production code), but I have a hard time encouraging the use of this technique in actual production.

Louis

I completely understand what you’re saying about “semantics” (and what others have said). But really, what it boils down to is that we want our code decisions to actually solve problems.

Although it feels “clean” to keep content and styles separate, in many cases it is not a benefit. Code should solve problems. OOCSS solves problems related to performance and maintainability. Overly pedantic “semantics”, solve very few, if any, problems.

I don’t necessarily think everyone should use OOCSS. If you think it can solve some CSS problems for you, then use it. If you think it creates more problems than it solves, then don’t use it. Or else use a pre-processor (as someone else pointed out). Whatever benefits your code.

But I do think it’s good for all developers to understand the concepts of OOCSS, which is why I wrote this piece. :)

0

5

John Slegers

I would love your input regarding a brand new CSS framework I released last week.

Cascade Framework is fully OOCSS, which makes it far more modular and flexible than any other CSS framework out there. In spite of being very feature rich, it has a very tiny footprint of between 2,5Kb and 10Kb minified and gzipped, depending on which features you want.

JC

I believe the objection here was not that non-semantic code was in use in CSS, but that those classes appear in the markup, which, in my estimation anyway, is there for content structure. The idea is to keep style references out of the markup.

1

8

easwee

Css has nothing to do with content semantics. I use classes like .i1, .i2, .w10 – whatever – and also google will not rank you any better if you name your sidebar .sidebar or .sb – you will only save a few bytes since you use shorter class names. The only benefit of naming your header div .header (if you’re not using header tag) is that when another programer comes working after you he will not have to do a search for what this class is since the name is logic. HTML TAGS are meant for semantic MARKUP – not css classes.

0

9

Joshua

One) The benefit of semantic class names to future developers (this includes our future selves) should not be underestimated. Good class names don’t just explain the structural nature of the elements they are applied to but also indicate the reasoning behind the structure used and the relationship between disparate elements.

Two) From the W3C HTML5 specification describing the use of the class attribute : “authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.”

The opportunities for content – and the markup describing it – to become portable is increasing as technologies and methods of access change. I don’t think it is unreasonable to expect that trend to continue. This means that it is worthwhile for us to consider the need for our content to be available in a variety of contexts and forms.

By focusing on and favoring semantics in both our choice of tags and class/id names we improve the flexibility of how our content can be presented across contexts. This doesn’t mean that there aren’t cases in which non-semantic class names provide a meaningful advantage but that should be the exception, not the rule.

3

10

dade

I’ve been using this method and the one great thing about it is you have to think about your site in a global sense. Before using this, as soon as I had a design, I’d see the main containers and just start pounding out code. This usually lead to a lot of code getting repeated and added unnecessary code.

With this approach, I take more time laying out this site, looking at the design and layout a lot more in depth. This allows me to find areas where I can re-use code and set those as the “prototype” classes and then add classes with the rest of the necessary styles (which is usually very little additional code).

In short, it’s not only made my sites faster, but it’s made me a better, more thorough developer.

1

11

Andrew Ford

I’ve been using OOCSS techniques for over a year on large projects with multiple front-end developers & back-end developers.

The CSS produced is far easily managed as OOCSS forces a structure. When developers are working on the same project they can check what’s already been created and reuse that styling, and/or add an additive class to make the variation they need.

I’ve also noticed benefits when the back-end developers can quickly add some CSS classes to elements and have a page 90% complete when page structures are similar.

2

12

Aaron Martone

Though the concept of better organization of CSS is tried and true, there is no need to add yet ANOTHER acronym to an already over-saturated market. I know everyone wants to coin the next term, but this is kind of out of hand.

OOP-ing an object usually only makes it more understandable to developers and not designers. There are a myriad of concepts that are perceivable by both which can lead to cleaner, more optimized CSS without the need to associate it with traditional OOP methodology.

Adrian Miu

On one hand, web developers don’t really have a problem with CSS classes poluting an element as long as they don’t have to do it. Look at all the UI frameworks (eg: jquery UI); to have a tabbed box you have about 4 classes added to the container, nativation and content holders. But that happens behind the scene and doesn’t count, right? :)

On the other hand, unless you work on an environment like yahoo it’s hard to imagine having the need to organize your html and css that rigorously and adding a few extra elements “just in case” . Most developers are part of small teams, project varies enough not to start thinking about abstracting the css.

I can see why this topic polarizes the audience so much.

0

15

Brandon

In general, you bring up some good points in this article but to a certain extent.
I believe it really comes down to the amount of re-usable code. Id selectors for css are slightly faster than class selectors… In other words, if ripping apart a couple of id’s css to share between lets say a few classes may actually be slower to render and potentially make your file size larger after adding the necessary classes/html. It all comes down to how much can actually be re-used between elements.
Also keep in mind that for the very few people that still need to support IE6, IE6 does have issues with multiple class selectors for elements.

RDO

Don’t forget about selector search speed through js/DOM. Selecting by class is substantially slower than selecting elements by id. Taking out ids in favor of classes will ultimately result in a slow page (if your page has lots of js element manipulation).

0

18

FuzzyJared

You would also have to consider how you are utilizing the js to select an item by class. Each id on the page should be unique; you should not have 2 ‘#widget’ on the page. So for multiple elements that you are looking to interact through js/DOM the ‘.widget’ class would be the only way to go.

0

19

Rick Lowes

@Brandon Actually IE6 supports multiple classes just fine (separated by a space, which is how they are used in the OOCSS framework). What it doesn’t support is “class chaining” (i.e: .class1.class2).
Also IDs are not proven to be much faster than classes..

0

20

Ross B

I believe IE6 supports extending 2 classes, just not over 2 classes… so class=”class1 class2″ works, but not class=”class1 class2 class3″ … Can someone else confirm this, I remember checking this about 2 years ago while doing this on a huge site and have forgot about it since then.

0

21

Brandon

IE6 supports as many classes as you need. You can have ten classes on it, if you need, provided you’re not using class chaining in your style sheet. In the second example provided below, only the last class which is chained is honored (.c3). One of the ideas of OOCSS is to start with a base class and add on to it with separate rules.

Brandon

@Rick, yes IE6 does support multiple classes… I said it has issues. OOCSS will generate more classes for elements at all levels, there is a potential of parent/child class selectors that may need to be selected. To fix the issue, an easy solution is to use the parent’s id selector… sort of breaks the idea a bit of using classes as your main selector. It is a potential issue that people may run into for IE6.

IDs are proven to be faster (although minimal). Your source proves it (though I wouldn’t use them as a credible source). As browsers continue to improve efficiency, it will continue to be less of an issue.

Basically what I am saying, its a judgement call for certain scenarios… and if you are lucky enough to support IE6, you should be aware of potential issues arising by utilizing just OOCSS as a solution.

0

23

James

ID will always be (on average) faster than class lookups since the node tree search exits as soon as it finds the ID (could be near the root) – with class lookups with entire tree must be walked since there could be an instance of the class both at the root and in the leaves. It’s not a bad or good thing, just that ID’s and Classes are there for different reasons and a different algorithm is used appropriately.

0

24

Rafal Borowski

Louis

From what I understand, the speed benefit of the ID selector vs. the class selector is very small. But yes, it is a benefit, so that’s something to keep in mind. But, if the module abstraction saves you hundreds of lines of code, then the benefits easily outweigh the drawbacks.

Also, IE6 does not have issues with multiple classes. IE6 has no problem whatsoever with multiple classes declared on an element — as long as the selector that targets the classes uses a single class.

The problem you’re referring to is when IE6 bugs out due to the use of chained classes in your CSS selector. So you can’t do this in IE6:

.one.two.three {
/* notice no space between the classes */
}

So as long as you aren’t chaining your classes, there is no problem using multiple classes on a single element in your HTML.

RDO

I tend to agree with you, Brandon. However, I’d like to emphasize the performance aspect. I think the performance hit of using classes instead of unique ids, can be significant (if used too liberally). Ideally you only use css classes for “base”/”outer” elements that are not used often, and then use ids for specific styles and let cascading take care of the rest.

0

27

Brandon

Pablo Fierro

Nice way of organizing styles, I’ve been doing it for a while now, the only issue with this is the use of non semantical css naming conventions such as “header-inside”. I just hate it when I see this type of css naming on a project I’m working on.

Wojtek Iskra

First of all, what you suggest about dropping descendant selectors for the purpose of possible reusability of a style in other places, is no OOP at all – well, maybe it kinda is, but with global written all over it. What you’d end up with is dozens of pointless classes for the same elements depending on their looks – that doesn’t seem like a good approach to me.
Yes, browsers read CSS selectors from right to left, so descendant selector are slower, but they resemble OOP classes much better.

Secondly, as others already stated, you use lots of pointless classes that trash your HTML semantically. Maybe I’m old school, but I still put separating content from the looks at the top of my priority list.

Louis

It’s true that “OOCSS” may be a misnomer, but that’s really beside the point.

Also, you said:

“What you’d end up with is dozens of pointless classes for the same elements depending on their looks”.

If your elements look different, you’ll end up with “dozens of pointless” rule sets regardless of whether or not you use OOCSS. So I think you’re not understanding the benefit here. You’re only abstracting the styles that you’re intending to reuse, so instead of a dozen unique rule sets with repeated styles, you’ll have a dozen unique rule sets with no repeated styles.

1

32

Wojtek Iskra

I get what you mean, but I don’t see why would you need several abstract classes for one element when you can achieve the same OOP-like inheritance by simply using selectors with different weights and rely on HTML structure instead of classes.
Common properties land in declarations with lower weight, specific ones in further down the road. That’s how it has always been – I don’t see a point in changing it now.
That way you reuse your styles like you want here, but still have semantically correct HTML.

Only upside of using such class hierarchy is that your selectors will be faster for the browser to work with – I give you that.
On the other hand, I’d imagine it would be much more difficult for other developers to step in in the middle of the project and catch up with your already elaborated syntax.

1

33

Leonardo Rothe

I would embrace the so-called OOCSS principles (you keep using “OO”; I do not think it means what you think it means) with a CSS preprocessor (LESS, for example), where you could pack recurrent styles as reusable declarations.

However, using the class attribute to apply styles is a step back, as we are involving the document itself into managing its visuals, which is NOT what CSS is all about. An exception would be web apps which heavily rely on a componentized UI, and even then, skinning is solely the UI toolkit’s business (using separate stylesheets and dinamically generated HTML which the UI toolkit library provides and manages on its own).

Documents where semantics matters should not need style-related stuff spoil its structure with that kind of hooks.

0

34

Tim

While I agree with you in regards to using a preprocessor like LESS or SASS, I think you miss the performance side of his argument. While LESS and SASS make developing a lot easier, it does nothing for performance. LESS and SASS consolodate CSS style so that you would develop the css in a similar way as OOCSS, but the css that gets sent to the browser, is the same css as if you hadn’t organized it at all.

0

35

Madj

I tried this myself some time ago, and I think it doesnt really help. Tearing the styles of an object apart means you have to check different places later if you want to change something. I therefore rather “duplicate” some properties but have all the information in one place. The thematical fragmentation of CSS files can help even more.

0

36

Michael

The only performance boost I read about in the article was by download. If that’s the case why not just argue for compression? As mentioned in the comments you can achieve a parsing speed boost too. Let’s see some benchmarks on the speed of the oocss vs non-oocss. Unless there is a real benefit there then you can take my original statement of arguing for compression and write an article about that.

0

37

Louis

Compression will be done on top of an already OOCSS driven stylesheet. Do you really need benchmarks for whether or not a 900 line CSS file would download faster than a 1500 line CSS file? Because that’s pretty much what it boils down to.

0

38

Michael

I don’t want a benchmark for download speed. I want a benchmark for execution time. Obviously the smaller file size is going to download faster. But, what’s the most efficient way to get the file to execute. If my 1500 lines executes 300ms faster than your 900 but takes only 200ms more to download….. well I think you see my point. All of this is unproven of course; which is why I’d like to see some tests.

0

39

Jason

It strikes me as interesting that “OOCSS”, as defined here, eliminates the use of descendant selectors, which I have used very successfully to namespace my styles.

For example, in a web app, different parts of an interface may require different styling for similar elements. If I have <a> tags with the class name “button” in both the menu bar at the top of my app, and also in a sidebar menu (but with different styles), I would use “#menubar .button” and “#sidebar .button”. I may have a generic style for the “.button” class elsewhere, but I want special styling when a button is within a specific context.

I have not run into any issues with this, but I would love to hear your take on this approach.

Louis

So in that situation, with OOCSS, you could accomplish the same thing with something like this in your HTML:

<button class="button-basic button-skin"></button>

So this frees you up to use the added “skin” class on any button, no matter where it appears. Nevermind the class names I’m using, these are just illustrative.

In a very large project, whatever “skin” you’re applying that makes the button slightly different in the sidebar will likely be used elsewhere too. So, this way, you don’t limit the use of that class to just within the sidebar. And if you need a different skin, just use a new class elsewhere.

And yes, I understand that you like the readability of “#sidebar .button” in your stylesheet, but when you factor in the code savings, the potential specificity problems, and the potential for reusability, I think the benefits outweigh that small drawback of code readability.

Really, with developer tools as powerful as they are to help track down styles, it shouldn’t be necessary to “namespace” your styles in that way. Plus, you can accomplish the exact same type of “namespacing” using good CSS comments.

0

41

Jason

I see your point. If suddenly I decide that the button styling in my sidebar would be perfect for a modal dialog, and a feedback form, suddenly I’m duplicating code or adding more selectors to my CSS rules.

Louis

The only problem here is that you’re “chaining” the classes in your selectors. You don’t want to do that with OOCSS, because they’re still not reusable. And chaining doesn’t play nice with IE6 (if you need IE6 support).

You want instead to have base objects (like .button) but then extend those objects with skins (like .compact or .icon). So the the “skins” could also apply to another element, not just .button.

Daphne

OOCSS can be unnecessary for smaller sites and teams so I can understand why most front end developers don’t feel the need adopt this method of CSS organization. However, the benefits are incredibly visible when it comes to large sites and large front end development teams.

You can end up with 10+ different pieces of content with incredibly similar styles. Duplicating properties makes CSS files huge over time. Without documentation of CSS classes, the same properties get defined over and over. Overriding IDs become a specificity nightmare between front end developers. The gains become much more apparent in file size and with developers of different CSS skill levels. Don’t forget checking out http://smacss.com too.

0

45

FuzzyJared

I think most of us have used OOCSS for a while without actually declaring it as such. I think the hardest thing to do with this method is to keep consistent naming convention that is intuitive to multiple people and to have a well sectioned CSS file. Otherwise you end up with the very oposite of what OOCSS can provide, a bloated CSS file with redundant / overlapping style declarations.

0

46

Max

tommy

Max, I checked your post but didn’t see anything, did you forgot to include the link to the “big news” that you’ve come up with? You’ll have to forgive me if not, with a smart-assed reply like yours, I figured you would be following it up with something ground-breaking.

If this is such old news, let us know why. Perhaps you can help the rest of us and the author better understand the topic in question. If your half as smart as you are rude, I’m sure we can all learn something from you. ;)

0

48

Gunnar Bittersmann

“Don’t use presentational or behavioral markup” is the 2nd of Jens Meiert’s basic rules .

But this OOCSS approach is just that: presentational markup. @class attributes just for the purpose of styling. It does not improve maintainability, quite contrary: On later style changes, you’ll end up changing @class attribute values in zillions of HTML documents instead of changing the code in just one file – the stylesheet.

“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” is not true. The compression algorithm (you serve your stylesheet gzipped, don’t you?) makes a file with repeated lines almost as tiny as a file with no repetitions.

Louis

“On later style changes, you’ll end up changing @class attribute values in zillions of HTML documents instead of changing the code in just one file – the stylesheet.”

Absolutely untrue. You’re thinking only of worst case scenarios, which would be a problem whether you use OOCSS or not.

“The compression algorithm (you serve your stylesheet gzipped, don’t you?) makes a file with repeated lines almost as tiny as a file with no repetitions.”

First, I’d like to see some proof of that because I highly doubt it’s true. Especially when we’re talking about hundreds of lines of CSS. Are you actually trying to say that 500 lines of CSS would not have an impact on a CSS file’s final compressed size?

Also, this is not a matter of either/or. In other words, you gzip regardless of OOCSS, so if you also use OOCSS to save hundreds of lines of code, then you’re getting the best of both worlds. Your comment seems to imply that OOCSS doesn’t get gzipped…?

So my advice is: Use OOCSS if it saves you significant amounts of code, and gzip your files regardless.

0

50

Carlo Rizzante

But with your approach, what about the characters you need to add on the HTML part of the website, Louis? Those counts, too. Your CSS will end up quite bloated, and the HTML too, filled up with descriptive, redundant classes.

I prefer leaving my HTML the purest as possible, describing the function, not the aesthetic, and styling it merely though the CSS side.

But thanks for the article anyway. It gave me motivation for writing about a total different approach.

0

51

Louis

As far as I can tell, the extra HTML is minimal but the potential for smaller and more maintainable CSS is very high. And “clean HTML” is, in my opinion, highly overrated. I may be addressing that topic another time. :)

But yeah, I completely understand if people don’t like this approach. It’s not for everyone. But I do think the principles should be understood and applied at least on some level.

Gunnar Bittersmann

“Absolutely untrue. You’re thinking only of worst case scenarios, which would be a problem whether you use OOCSS or not.”

No, it’s no problem when the markup was written not thinking about styling. Then you just change the stylesheet without touching the markup again.

OOCSS and separation of content (HTML), presentaion (CSS) and behavior (JavaScript) are both optimizations – with different goals. I prefer the latter.

“First, I’d like to see some proof of that because I highly doubt it’s true.”

Why haven’t you tried? Well, I did. I took the Universal Declaration of Human Rights whose text takes 11017 bytes. Gzipped: 3915 bytes. Appending the same text again makes the uncompressed file twice as large, of course. Not the gzipped file, though, it takes only 4411 bytes. Another repetition: 33 kb become 4736 bytes. That’s how compression works.

0

53

Louis

Interesting results. I did a test using an online tool and got different results. I tested my own CSS file, and it Gzipped from 35,000 bytes down to about 8,700. Then I doubled the size of the CSS file and the gzipped result was over 16,000 bytes.

I’ll do some further tests, because this is definitely something worth looking into a little more deeply. Thanks.

0

54

Abid Omar

Something is terribly wrong with this post. The way you structure and plan you CSS code has nothing to do with the Object Oriented Pattern. OOP is a pattern. It’s when you have a class model and can create new objects with it.

This is terribly confusing.

0

55

Louis

OOCSS is probably a misnomer (I didn’t coin the term, I’m just explaining the concept here). But generally speaking, all CSS developers understand that CSS is not programming, thus this should not cause any confusion to anyone who knows how CSS works.

OOCSS helps you create reusable class-based modules that can be reused anywhere, and that can be extended with other classes. That’s the gist of it. There’s no need to compare OOCSS to OOP; that’s a topic for another post. :)

Also, the word “object” is not an English word that’s reserved exclusively for object oriented programmers. It’s a word that means whatever a dictionary defines it as, so there’s no reason it can’t be used to describe a method to organize your CSS.

0

56

Rajeev J Sebastian

OOP is a philosophy more than a set of features in languages or compilers. The focus of OOP is not classes: rather they are objects. It is the idea that many different individuals share common traits and therefore can be grouped/described/etc by a class or prototype; further, that classes and individuals themselves may be organized through (class and object) patterns such as aggregation, inheritance, mixin, delegation and so on; that individuals can communicate among each other also following patterns such as methods, messages, etc.

Why can’t this be applied to CSS? My exposure to OOCSS itself is minimal, however I can see the appeal. Languages such as LessCSS, as well as new CSS3 features, allow to create such OO organizations with browser, compiler and language support. For e.g., using mixins. XBL binding is very clearly OO in nature.

Multiple classes on a single element can be compared with inheritance (.button, .button.submit, .button.add.entry), and it is easy to see where the concept of “HTML/CSS class” originates.

The addition and removal of classes on a given element triggers a “message” or “method”, which is utilized to implement CSS3 animations. I mean, that an addition or removal of a class, could trigger a “process” of change.

The list goes on… I could argue that we already use OO concepts when writing HTML, CSS and JS. The only question is, how can languages, language extensions and frameworks help us formalize this. LessCSS and Mootools are very good examples for this.

On the other hand, specific recommendations about what kind of class names to use, avoiding certain selector types are hard to accept. This OO formulation of CSS seems to me to be too simplistic.

0

57

Carlo Rizzante

This way you pollute your HTML with descriptive classes for the mere purpose of aesthetic reasons. Not a good idea. We should aim for a pure semantics in our HTML.

It’s very possible to keep your CSS simple and ordered. Tools like LESS and Sass are there to be used. They are a good fun, too. And wouldn’t be brilliant to be able to style your HTML without having to change a comma in it, just via CSS?

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book →

Meet the new Sketch Handbook, our brand new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work. Get the book.

Meet SmashingConf San Francisco 2017, featuring front-end ingredients, UX recipes and nothing but practical beats from the hidden corners of the web. Only practical, real-life techniques and recipes you can learn from. Get your ticket now!