Brain vs. Object Oriented CSS
I have been using Object Oriented CSS ( @stubornella’s creation ) for a little over a month now and have learned some important lessons along the way. My decision to start using the oocss approach was based purely on the fact that my CSS was getting sloppy. I was using different CSS code on various pages of my sites, even if those pages shared the same design component. This was a waste of development time, and ultimately page speed ( code was duplicated ). Using oocss allowed me to code common design blocks in HTML/CSS once, and drop those blocks of code anywhere else on the site. Dropping blocks of code onto an HTML page could be done without affecting the code block itself or the outlining code. This was a huge win, however, with benefits come drawbacks, and the biggest drawback to oocss, in my opinion, is accepting oocss for what it’s worth. At first, your brain will fight it every step of the way.
Most developers minds are trained to code one way and one way only, and all other ways just don’t make sense or they’re taking a step backwards in the CSS/HTML development approach. So when developers, new to oocss, see the techniques for the first time, most of them ( myself in this case ) fight it…fight it…fight it…and fight it…
- Why would you ever put several classes on one HTML element. This is what inline CSS styles used to do? This is a step backwards in front end development.
- Why would you ever add an extra container <div> just to add a skin to an HTML page?
- What about margins and padding? I need my site pixel perfect. How does oocss solve this problem?
- CSS3 comes with complex selectors; not using them is like taking a step backwards.
The mind of the developer will continue to fight against using every step of the way. And that alone is one of the problems with learning Object Oriented CSS, if the developer keeps fighting it, they can never truly absorb what it is all about. The day I told myself, “Screw it, I’m going to put all my fundamental CSS HTML approaches aside, and just soak up oocss.”, is the day that oocss started to become a little more clear. Things like —> separating content from container and structure from skin, started to make a little more sense. Things like —> adding multiple classes to HTML elements, was ok. Things like —> adding spacing classes, like .pan, .mal, and .prm to elements, was not a perfect solution, but it would do for now.
Once I finally accepted the principals around oocss, it was much easier to start developing a site using it. However, when development began, my brain continued to fight it. It was like I was a drug addict who had a relapse. My mind was craving for the easy route, and at that route was going back to my old coding ways. Fortunately, I stuck with the oocss approach and continued to develop the site with oocss theories.
Soon after that setback, after setting up all of the CSS/HTML objects, it was time to place those blocks of code into templates within a site. This is the day that Object Oriented CSS made so much more sense. It hit me — you could literally take any block of HTML ( as long as it had the proper CSS classes ) and drop it anywhere, on any page within a site. The page would not break and the block of HTML would not break either. This was the Eureka moment.
Ever since that moment, I have embraced oocss and have been trying to learn more and more. Don’t get me wrong.. there are still some fundamental problems with it, but the benefits of learning oocss alone, even if you decide not to use oocss, will make you a better front end developer. Believe me your brain will thank you for it.
