##Articles
An Introduction To Object Oriented CSS (OOCSS)
Great intro from Smashing Magazine on the topic of OOCSS. On the topic of a multi-class approach to declaring styles:
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.
About HTML Semantics and Front-End Architecture
by Nicolas Gallagher. I love this article so much -- it says it all (IMO) perectly. Amongst other things, great talk about semantics as well as why he prefers a multi-class approach vs. that of @extend.
If you use a pre-processor, you might use Sass’s @extend functionality to reduce some of the maintenance work involved in using the “single-class” pattern. However, even with the help of a pre-processor, my preference is to use the “multi-class” pattern and add modifier classes in the HTML.
I’ve found it to be a more scalable pattern. For example, take the base btn component and add a further 5 types of button and 3 additional sizes. Using a “multi-class” pattern you end up with 9 classes that can be mixed-and-matched. Using a “single-class” pattern you end up with 24 classes.
Obviously, read the article for more context and the matching code examples for this and other points he brings up.
Our Best Practices Are Killing Us
Nicole Sullivan makes the case about how some of our long-held, beloved HTML/CSS best practices can in fact make our jobs much harder than they need to be. This article is a to-the-point simple assertion of the high level points of this argument.
Defending Presentational Class Names
by Philip Walton. Great article asking the question: should presentational class names always be avoided or is that too dogmatic? He asserts that ss web development changes, perhaps it's time to reexamine the issue. Some great insight and thought about the benefit presentation class names, the possible downfalls of heavy pre-processor use, and ultimatley the belief that each team should examine their own process and find what works for them.
Against dogmatic thinking:
Best practices for writing front-end code shouldn’t be dogmatic. They should be based on whether or not the advice actually helps the development process. As web technology changes, what was once sound advice will not necessarily always be so. We have to continually examine our best practices and only use them if they make our lives easier.
On the argument that "class names should be semantic":
I fully support the use of semantics in HTML documents, but semantics can only be derived from markup when there’s a universally agreed upon meaning to that markup. HTML elements and certain HTML attributes have established semantics, but classes do not. A browser, screen-reader, or search engine cannot and should not be expected to parse your class names and guess at their meaning.
Presentational classes and reusability:
If a class name is used to describe the content, that class can only be used where that content exists, but when a class name describes a visual pattern, it can be used in many more places. The more abstract the visual pattern, the more reusable the class.
Naming UI components in OOCSS
Nice article from CSS Wizardry looking at naming UI components in OOCSS, and how we might do so (using the HTML data attribute) in a way that keeps class names focused solely on presentation. Also, he begins the article with a few thoughts on HTML and class name semantics, echoing the well-articulated points made by Nicolas Gallagher in his famous article.
The Future of OOCSS: A Proposal
Much of this article examines in great detail where and how pre-processors fall short, the problems they can cause, etc.
What Makes For a Semantic Class Name?
by Chris Coyier. This isn't really OOCSS focused, but I wanted to include it as a nicely written piece about semantic class names in HTML (with helpful examples). I'm stil learning, but it seems like his opinion on semantics differs from that of Nicolas Gallagher, etc in some respects. Relatedly, I do like this final point in the last paragraph regarding OOCSS:
"As I understand it, that's OOCSS. Sacrificing a slight bit of semantics for the greater good (drastically smaller resources)."
Naming UI components in OOCSS
from CSS Wizardry, nice article here on how we might name UI componenets in our OOCSS authoring. How can we describe the content in a way that doesn't conflict with our reusable and content-agnostic style-based class names? Read the article for thoughts on it, but the tl;dr version is:
Keep using agnostic, abstract, OOCSS classes in your markup, but add any desired meaning to your HTML via a
data-ui-componentattribute, e.g.:<ul class="ui-list" data-ui-component="users-list">.
Also, it is worth noting that he begins the article with some good insight into semantics, and how they apply to HTML and class names (with the invocation of Nicolas Gallagher's excellent article on the topic).
CSS Ramblings
Really, very wonderful article from Adam Morse that well articulates his thoughts and opinions on OOCSS, semantics, dev velocity, workflows, etc. Incredibly well-rounded, pragmatic, and wholistic approach to this entire topic.
##Videos
Object Oriented CSS (Nicole Sullivan, 2009)
I believe this is her first talk on OOCSS from 2009. Focuses on CSS basics, bad habits that front-end engineers typically fall into when writing CSS, and proposes a set of solutions / best practices in the OOCSS ilk. No mention of preprocessors (which surely didn't exist like they do today), which is actually nice -- keeps things focused on the CSS.
OOCSS and Preprocessors (Nicole Sullivan, 2014)
Basically an updated version of her 2009 talk. She focuses largely on how preprocessors can be useful, and talks about how they might be married with an OOCSS approach. While espousing the use of preprocessors, she does a great job giving warnings about how they can be used poorly -- and shows great examples of the final output CSS in worst-case scenarios.
Tuts+ OOCSS Intro
Short (15m) and simple video giving a nice OOCSS intro with examples. Helpful along the lines of the presenter showing how we "used to" write things (or the "bad way" to write things), and then shows the OOCSS alternative and why it is preferred.
BASSCSS: Next-Level CSS Toolkit
by Brent Jackson. A terrific framework whose approach resonates with me greatly. From the official description,
BASSCSS is a lightweight collection of base styles and simple type and layout utilities designed for speed, performance, and scalability. Use it out of the box for simple sites and prototypes or as the base for a larger SASS project.