Object-Oriented HTML, and OOCSS

Published on August 6, 2013 (↻ February 5, 2024), filed under (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

“Object-oriented CSS” is the idea of treating page elements as objects, giving all these objects classes, treating objects’ classes as single entities in style sheets, and taking it from there. I’ve never commented on OOCSS as it was never relevant for my work. As supposedly so useful it should have been relevant though, so it piqued my interest and I reviewed the old OOCSS site and Smashing Magazine’s introduction.

Objects and HTML

The idea of objects in HTML seems generally compelling. I was interested in a possible terminology, and jotted down the following:

Objects and CSS

Now we meet OOCSS, and I think we’re dealing with a misunderstanding of HTML and CSS:

  1. There are different types of objects in HTML, and without a clear distinction (as attempted above) an object-oriented approach seems misguided. There are completely different levels of interaction and complexity between simple, complex, native, and external objects.

  2. There’s nothing wrong with IDs; IDs are rather an important part of the cascade. Similarly, there’s nothing wrong with descendant selectors (performance? that argument is none); these are also important. In my view, depriving authors of these cannot be an option.

Suggesting authors to think objects without proper differentiation and then to stay away from vital parts of CSS is not enough to establish a different web development technique, let alone paradigm.

The arguments set forth with OOCSS are furthermore contradictory (easier to use but learning curve, good for performance but also not). OOCSS supporters even admit OOCSS to be problematic (“for smaller sites and apps […] OOCSS would be overkill”).

This is not good. It’s not a sign of our maturity that the topic of object-oriented CSS, conceived in 2009, isn’t entirely clear—or dead by now.

A note for the sake of the good old times: I’m a fan of tailored, quality code. As I pointed out in the past, if you prefer off-the-rack stuff, that’s fine—no one will swing the quality bat at that.

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you want to do me a favor, interpret charitably (I speak three languages, and they can collide), yet be critical and give feedback for me to learn and improve. Thank you!

Comments (Closed)

  1. On August 7, 2013, 9:12 CEST, Raphael said:

    Hi from France,

    The “object CSS” (what a terrible name) are only useful for reusable behaviors (.module, .row, .clearfix, etc..) and this is also why the HTML classes were created at the beginning: to classify / group HTML elements on a common affiliation.

    In the case of complex, single or external objects, the concept of “object CSS” has no reason to be: use a name (using id or class) for the “special” items.

  2. On September 1, 2013, 6:32 CEST, Randy Merrill said:

    A lot of these things are things that seem to be solved by the work being done with web components and projects like Polymer.

    The idea of taking complex objects and either provide your own interface for styling, events, and logic in self contained units.

    There is a lot of things still to be done on it but it allows for developers to create their own ‘object’ elements.

    It also works well for embedding external components into pages since the component controls everything unless it gives specific access to the internals.