Preface
Oxygen is an object-oriented approach to CSS. It is designed to give teams a simple and consistent way to communicate about stylesheets. It is one part a set of naming conventions and one part a way of thinking about CSS. It seeks to take the best of Object-Oriented Programming and apply it to how we write CSS.
Anyone who has had to work with CSS on a long running project knows that maintaining a long running CSS project is extremely difficult. Even if you write all the code yourself.
Andy Hume said it well in his talk CSS for Grownups at SXSW Interactive in 2012:[1]
“It is almost a challenge to find a development team that is working on a code base that is more than a couple of years old where the CSS is not the most frightening and hated part of the system.” –Andy Hume
“The most frightening and hated part of the system.” How often that has been your experience with CSS? Especially with CSS that you inherit from others?
CSS as a language has been around for over 20 years now. And we are still struggling to understand how best to write it! Why is this?
My belief is that the fault lies at least part with the division of labor in the Web community. For a long time now, projects have been divided between designers and programmers. Oddly, the frontend has mostly been the domain of designers, while programmers have been delegated the complicated work of backend programming and databases. This is not to say that programmers don’t write CSS, just that the major movers and shakers in the CSS community have been designers or have had a design background of some kind.
And even when programmers write CSS, they tend to look to designers as the experts on how CSS should be written. And designers have mostly been concerned about the output of CSS (the visual results).
Just look at how the language has evolved over the years. It continues to gain features that make it easy to accomplish things like rounding corners and adding drop-shadows. Heck, it’s even getting features like the ability to flow text around non-rectangular shapes! But the syntax of the language has changed very little, with few improvements.
The focus has been almost entirely on the visible output of CSS.
Thankfully, this is beginning to change. In part, this is due to the rise of a new kind of programmer. The frontend programmer. Frontend guys are still considered lightweight programmers, but they are beginning to ask the right questions about how CSS can be improved and how concepts from programming can be applied to CSS.
This is most visible in frontend frameworks like Bootstrap and Foundation, but it can also be seen in the rise of modular methodologies for CSS. Methodologies like SMACSS, BEM, OOCSS, and Atomic.
Not to mention, Oxygen.
Why you should choose a CSS methodology
Wherever you fall on the designer/frontender/programmer spectrum there is something you need to embrace about yourself:
You write code for a living.
And, if you write code at all, you should care about how it is written!
Especially if you write code that will one day be used by others. (Almost all of us do!) Code has a way of living on longer than we plan. (Even “throw away” code.) The sooner you come to grips with this the better. The code you write will one day be used, edited, rearranged, and extended by others! If you care about the people who may touch your code in the future you should care about how it is written.
Most of us are guided by a handful of practices that we pick up from others and through experience. The trouble is, we all have a different set of best practices. This is what makes it so hard to collaborate over CSS. And also why you may have had the urge to rewrite someone else’s.
Now maybe you already know how you want your CSS to be written. You could document it yourself. Take the time to spell out the ins and outs for the team of people you work with. But this takes time. Precious time that you could use to make better progress on other projects that are competing for your time.
This is where an off-the-shelf methodology like Oxygen can help. It can give you a backbone for your CSS projects. And it can do so with far more detail than you probably have time to write out for yourself.
A written methodology also frees you from the tyranny of personal opinion. Instead of arguing about how it should be done you can just refer to the methodology. “We use Oxygen here in our workplace.” Or, “Oxygen plus this and that.” Whatever the standard is… Need help explaining a particular naming convention or principle? Link your co-worker to the relevant page…
Introducing Oxygen
Oxygen is named after the O2 molecule (known as “molecular oxygen”). Also notated as O-O. This is could also be a way of abbreviating Object-Oriented. Oxygen seeks to take principles from Object-Oriented programming and make them accessible to people who write CSS. It’s building on one of the finest traditions for organizing code ever invented with roots in programming stretching back to the 1950s.
Object-Oriented code is a great fit for user interface design. We naturally speak in terms of objects when talking about “buttons”, “menus”, and “controls.” Oxygen encourages you to name these objects in your code. The more you do it, the more you will find that your code “speaks” to you and is is self-documenting.
Object-Oriented code is also “modular” which means it is highly reusable. It helps you break your code into “legos” or small building blocks that can be used to build up larger components and interfaces.
As it turns out, the more you use a methodology like Oxygen on a project, the less time you actually spend writing CSS. Why? Because you’ve built up a library of small reusable objects that allow you to achieve an large variety of designs without writing new code. Your goal on a mature CSS project should be to write as little new CSS as possible.
Why choose Oxygen?
Oxygen isn’t the only modular CSS methodology. What is it that makes it unique? Why should you choose Oxygen?
In a nutshell, it’s the terminology: Oxygen is distinctively object-oriented. In putting it that way I don’t mean that other approaches aren’t object-oriented. What I mean is that Oxygen seeks to map as many concepts as it can directly into Object-Oriented terminology. So instead of Blocks and Elements and Modifiers (in BEM terminology), Oxygen uses language like Objects, Child-Objects, Subclasses, and State.
If you are up-to-date with other approaches to modular CSS, you may wonder how this differs from Nicole Sullivan’s work on OOCSS. When I first heard about OOCSS I was initially quite excited. Finally, someone was trying to take the principles of object-oriented programming and apply them to CSS! However, as I looked more closely at Nicole’s work on OOCSS I realized that it was not a general purpose approach to object-oriented design in CSS. Instead, it outlined a way of working with CSS that worked well for Nichole at Yahoo (and works well for a large number of similar sites). In her work on OOCSS, Nichole focuses on the separation of “structure from skin” and on “containers and content”. But these are actually patterns of object-oriented design – not the only way of using objects in CSS.
Objects themselves deserve more attention! And this is exactly what Oxygen is all about.
Acknowledgements
In creating Oxygen, I’ve borrowed from a number of other frameworks and methodologies. SMACSS, BEM, and OOCSS to name a few. I’ve also been inspired by conventions in frameworks like Bootstrap and Foundation. I’m especially grateful for the guiding voices behind these methodologies and frameworks. People like Jonathan Snook, Nicole Sullivan, and Mark Otto. You inspire me.
Finally, I’d like to thank my wife Sarah. For letting me carve out time from countless weekends and even a few vacations to work on this. Your support, confidence, and smiles mean more to me than I can say. Thank you.
This book has grown out of my desire to influence a whole new generation of makers and builders on the Web. It’s taken a long while for me to arrive at some of the principles and opinions outlined here. I wish that someone had been there to guide me when I was learning CSS nearly 15 years ago.
Modular CSS as a movement is just getting started. I’m excited to be part of it!
Watch the video of Andy’s talk on YouTube or flip through the slides on Speaker Deck. ↩︎
Discussion