Object-Oriented HTML, and OOCSS
Post from August 6, 2013 (↻ December 12, 2016), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: 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:
Simple objects: elements (headings, paragraphs, &c.).
Complex objects, or composite objects: multiple elements combined (for articles, widgets, &c.).
Native objects: developed specifically for a site or page.
External objects: all-purpose, both by other teams (like a video module developed by other in-house developers) or of truly external origin (like Twitter or Facebook widgets).
Objects and CSS
Now we meet OOCSS, and I think we’re dealing with a misunderstanding of HTML and CSS:
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.
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. Depriving authors of either cannot be considered 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, well, just set that expectation and I won’t swing the quality bat 😊
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
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.
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.
Have a look at the most popular posts, possibly including:
Looking for a way to comment? Comments have been disabled, unfortunately.