The top comment by M. Andrews says it best:<p>"This is a well-written and well-argued piece, but I have to ask: have you ever built a large site with many templates, components and layouts? This approach is arguably impossible to implement for that context, not to mention inappropriate. Yes, CSS3 has some fairly advanced selectors, but littering your stylesheet with HTML-dependent stuff like “section ~ article h2″ is only going to cause you pain when you want to refactor, or simply target headings that don’t follow a section. Either you end up with 20-line-long lists of selectors, or you’re afraid to touch your HTML structure in case everything blows up.<p>I really don’t follow your argument about elements looking the same in different places being aggressive/inappropriate. Have you ever designed a user interface? The goal is to produce consistent and reusable components that the user will intuitively recognise and use. If my “post comment” button looks different each time I put it somewhere new, what kind of experience does my user have? Do my comment counts decline as a result? This doesn’t just effect nerdy semantics, it’s real-world usability too.<p>Finally, I don’t really buy your argument that we should avoid using classes because some mysterious third party content providers might use our entire HTML structure and it won’t look right. If we designed for that use case we’d all have sites like Jakob Nielsen’s (eg: plain and vanilla). It’s also possible to use semantic markup (blockquote tags for quotes, etc) <i>and</i> use classes, they’re not mutually exclusive. Also, if somebody pulls in my HTML which uses my custom classes, who says they have to load my CSS too? The classes won’t impact their site’s design unless there’s a naming overlap.<p>In summary: classless HTML might work well on small, mostly trivial sites, but long term, it’s not scalable or modular (as Jonathan Snook’s SMACSS framework explains)."
This feels like a terrible idea, something totally academic rather than usable. I practice the exact opposite, using classes <i>everywhere</i>, and virtually <i>never</i> attaching CSS rules to element names.<p>This is because, in my real-world experience, HTML structure can change very easily. The h1 turns into an h3 for SEO reasons, a wrapper div gets added for a visual effect, an extra span gets thrown inside an existing one. And suddenly, all the CSS is broken because it all depended on the <i>exact</i> structure of the HTML. Maintenance becomes a nightmare.<p>But if you do everything with named classes, then nothing breaks at all. Writing CSS without classes makes as much sense to me as writing JavaScript code without function names.
I did this once, I quickly abandoned it as I felt it was madness. It was for my personal site (just like his) that's a testing ground more than anything. After writing far more styles than I felt was necessary for such a simple page it was easy to see future problems once it was done. Biggest example as many pointed out is that if I moved HTML elements around in the markup then I would have to rewrite huge chunks of the style sheet even though I wasn't changing the actual design of the elements.<p>My soon former job involves two websites that have a large chunk of its markup with no classes or ids provided by the CMS. It is a nightmare to support or to add a new feature. I have a selector that is eight elements deep, all to target one cell in a table embedded in other tables. Well, to be fair, I'm guessing the author wasn't considering that kind of site. I can scare you at the campfire with stories of the tables I deal with that have no classes or ids. We've rewritten a good chunk of the CMS to clean up the markup and add classes to make my life as a front-end guy much easier.<p>This reminded me of the tables, I need some quiet time now.
I think just using a lot less classes, in combination with these selectors, would get most of the benefits without seeming so dogmatic and crazy. I guess most people "grew up" with half-finished CSS support (or if they're software like Drupal rather than people, they've not yet been refactored to reflect current browser capabilities) and so don't feel comfortable with the further reaches of CSS, but I find it quite liberating to use nth-child() instead of putting .odd or .even classes on things.
I found this article extremely thought provoking.<p>The rhetoric is the design community has been content first design, and such a bold choice in CSS authoring would really support this idea.<p>I would love to try this out in a real project.
While I don't agree at all with the idea of abandoning classes for clever ancestry-driven selectors, the author is absolutely right about the advantages of the HTML5 content model and the portability of semantic markup.<p>I wish more people would advocate for a middle ground between this content driven approach and an OOCSS approach. They work so nicely together.<p>Who ever said that you should stop caring about using semantically correct tags when using portable classes for styling?
Aside from the flaws in this, summed up very well by the top comment, I was quite taken aback by his swipe at Drupal. He links it to a tweet from 2009 that's taken out of context and references one particular Drupal module. It's a very flexible CMS/framework - if you're building Views it's up to you to customise the output to your liking. He's demonstrating a rather poor and naive understanding of it.
In my experience, styles that are applied directly to elements cause more problems than they solve. Outside of a minimal reset, and a few general elements like h1, h2, etc., I try to avoid applying styles to base elements. I have yet to see any real-world problem with classes. And I really don't understand why "classitis" is a concern for anybody.
It appears that where he is going is only as far as a small blog stylesheet. I appreciate his argument about context being important in styling, but it creates a very fragile stylesheet that could crumble with a simple change of the context. If you're updating often, this would just be too difficult to maintain.