

Classes? Where We’re Going, We Don’t Need Classes (CSS) - Couto
http://coding.smashingmagazine.com/2012/06/19/classes-where-were-going-we-dont-need-classes/

======
valuegram
The top comment by M. Andrews says it best:

"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.

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.

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) _and_ 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.

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)."

~~~
stinky613
To wit: browsing the article's source code and searching for "class=" yields
1158 results

~~~
lowboy
This is unfair - the author of the article has no control over
SmashingMagazine's markup/CSS.

~~~
stinky613
_> In summary: classless HTML might work well on small, mostly trivial sites,
but long term, it’s not scalable or modular_

 _> > To wit: browsing the article's source code and searching for "class="
yields 1158 results_

I wasn't suggesting the author was responsible for Smashing Magazine's source;
I was demonstrating that sufficiently complex websites have good cause for
using classes. Styling all of that markup without those classes would be an
absolute nightmare.

------
crazygringo
This feels like a terrible idea, something totally academic rather than
usable. I practice the exact opposite, using classes _everywhere_ , and
virtually _never_ attaching CSS rules to element names.

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 _exact_
structure of the HTML. Maintenance becomes a nightmare.

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.

~~~
heydonworks
When the HTML structure changes, the CSS changes in accordance. That is what
is supposed to happen. You do not understand the technology.

------
talmand
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.

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.

This reminded me of the tables, I need some quiet time now.

------
ZeroGravitas
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.

------
lukeholder
I found this article extremely thought provoking.

The rhetoric is the design community has been content first design, and such a
bold choice in CSS authoring would really support this idea.

I would love to try this out in a real project.

------
akdetrick
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.

I wish more people would advocate for a middle ground between this content
driven approach and an OOCSS approach. They work so nicely together.

Who ever said that you should stop caring about using semantically correct
tags when using portable classes for styling?

~~~
heydonworks
Ancestry driven selectors are the essence of CSS. Classes are a cludge.

------
justafish
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.

~~~
valuegram
While I agree that his jab at Drupal is off base, because I don't agree with
this article in general. Drupal does make extensive use of classes in its
templating system, so I can see why the author would have a problem with it.

I see the class functionality in the templating system as a benefit, and makes
styling much easier, but for someone who dislikes classes, I can see why the
author wouldn't like Drupal.

~~~
rjknight
I think this issue generalizes to other content management systems. Drupal
aims to allow users to create sites without needing to understand the
underlying HTML, and most general-purpose Drupal modules produce class-heavy
HTML because that is, once you understand the class naming conventions,
relatively easy to style without needing to change the HTML structure.

This represents a trade-off - 'uglier' HTML and extraneous CSS classes in
return for a drastic reduction in development effort and the knowledge
required to bootstrap a typical project. This trade-off makes sense if an in-
depth knowledge of HTML is not your strong point (and even most web devs are
not fully-fledged "front end developers" conversant with the finer points of
the W3C's latest magnum opus), and if you would benefit from having a lot of
boilerplate stuff (user registration, access control, content management, RSS,
caching, RDF, email notifications, widgets/blocks, templating engine, etc.)
for free. Sure, if you're willing to do all of that stuff yourself, you can
ensure that no CSS class is wasted (or, indeed, no CSS class is used at all).
But most people can't make that trade-off, and even those who can would
struggle to justify it beyond the most trivial or superficial projects.

The best solution is probably to take a framework and modify its output to
look the way you want it to. That's why the swipe at Drupal is odd, as pretty
much everything Drupal does can be modified via hooks (kinda like AOP) and
templates.

------
rralian
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.

~~~
heydonworks
What is a style "applied directly" to an element if not a class? It's written
on the element itself.

'Classitis' is certainly not a concern for parsers because they do not know it
is going on. Then again, that's my point.

------
dmauro
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.

------
suyash
This article has bunch of stuff but the author doesn't clearly justify the
premise. Much a read about nothing.

------
brianfryer
"In English, a verb cannot be substituted with a noun"

I beg to differ. You should Google that.

~~~
LeafStorm
Technically that's turning Google into a noun rather than replacing a verb
with a noun. You still conjugate it as "I Googled," "I will Google," or "I
like to Google things." English's lack of inflection in the "base" forms of
words just tends to obfuscate parts of speech somewhat.

------
RyanMcGreal
Not to mention that classes are very handy for attaching javascript event
handlers.

------
rsanchez1
If only all projects could be as easy as the examples presented.

~~~
heydonworks
Read my comments for the original article carefully. Projects are made easier
to maintain by foregoing classes.

Element names belong to a shared lexicon which all developers and sufficiently
up-to-date parsers understand. Classes are invented per project. They are a
superimposition. They muddy the water.

