Menu Search
Jump to the content X

Classes? Where We’re Going, We Don’t Need Classes!


Classes, classes, classes everywhere. What if we don’t need CSS classes at all? What if we stopped worrying about how many classes we’re using and what we should be calling them and just finished with them once and for all? It would be no revelation to you to say that HTML elements can be styled without recourse to the class attribute, but have you considered the multitude of benefits that come from forgoing classes altogether?

In the article, I’ll demonstrate that the class is as antiquated and inappropriate for styling as the table is for layout, and that omitting them can discipline us to create more usable, reusable content. I appreciate that this is a contentious subject; I’ll meet you in the comments.

(For those who aren’t “of a certain age,” the title of this article is a play on a famous line1 from the 1980s film Back to the Future.)

It’s Not About Maintainability Link

In her recent presentation “Our Best Practices Are Killing Us2,” Nicole Sullivan addresses the horrors of maintaining inefficient style sheets. Sullivan offers some helpful ideas and observations, especially for dealing with the convoluted code of major longstanding clients. My approach is more cavalier; if the style sheet schema I’m dealing with is so convoluted that it could affect the website’s performance all by itself, then I’ll do one of three things:

Maintainability is a problem, but it’s a problem for coders by coders, and CSS classes, as Sullivan points out, aren’t even the main culprit. The class attribute is implicated in a much graver crime, and usability—not maintainability—is ultimately at stake. Rather than the overuse of classes4, I question the efficacy of the class attribute per se.

The Class As Imposter Link

A few years back, a girlfriend of mine gave me the pet name Stinky. I appreciate that this might seem off topic; please bear with me. She assured me that the name was actually not due to any malodor, but rather had some cryptic link with a fond childhood memory. Nonetheless, it was not a moniker that I wished anyone else to know about. Well, until now—but it’s important for my argument.

Name label5
View image6.

CSS classes7 are a lot like pet names. They are coined in private, where they belong and usually remain, and on the rare occasion that they are aired in public, they’re frequently a source of great embarrassment. While I’m embarrassed to have disclosed my own pet name of Stinky (there it is again), I feel equally red-faced about the .nudge-right class that I once used to deal with an awkward div.

Not all classes are ugly hacks. Many frameworks8 employ sensibly named classes, sometimes even in an “object-oriented” fashion. The question is, why have classes at all? We already have the names of elements (<p>, <small>, <address>, <ul>, etc.). Better still, like my legal name of Heydon Pickering, they actually have some currency: they can be interpreted by more than one or two people.

Parity And Disparity Link

The reason we “mark up” Web content is to create parity between the way it is perceived by human readers and the way it is read and archived by machines. This parity has many benefits, some of which are discussed in an excellent post by Dr. Mike9. Perhaps the greatest benefit is that when someone searches for some content, the engine that carries out the search request has a better chance of identifying and finding it. The machine and the human have “an understanding.” Parity is extremely important because, without it, the mechanisms of data storage and retrieval would get out of sync.

Aside from microformats10 (which, like tag names, have been endowed with agreed meanings), no class is able to affect the actual meaning of the marked-up content as read by an indexing bot or screen reader. Classes can only affect the visual appearance of the content. That’s right: all classes are “decorator classes.” You knew that already, but is it a moot point? I think not.

An Example Link

Please consider the following code and corresponding illustration. Think of the tags as pseudo-HTML.

// HTML:

<crustacean class="crab">Shane</crustacean>
<crustacean class="lobster">Martin</crustacean>
// CSS:

sea {

crustacean {
   border:2px solid;

.crab {

.lobster {

(Images: Patrick Tanguay12 and ajmexico13)

  • What the human sees
    An angry-looking crab and a yellow lobster next to each other in a watery blue box, bearing the unlikely names of Martin and Shane, respectively.
  • What the bot sees
    Two adjacent bits of text that both belong to sea and should be treated as crustacean-related.

Both the human and the bot are correct. However, they are both missing some information. The bot is not aware that the two crustaceans are, specifically, a crab and a lobster. The human, meanwhile, has not been told that the crab and the lobster both belong to the crustacea family. Despite a correct use of semantic HTML and a judicious application of CSS classes, there is a disparity between the way the machine and the human interpret the information.

We can’t expect the specification14 to contain a tag for every conceivable concept. It will be no surprise that <slippery>, <disappointing> and <airborne> are not so far being considered for HTML5. Neither could we expect parsers to be able to meaningfully interpret each and every individually authored class name. In this case, what else can we do to supply both the human and the bot with as much of the same information as possible? That is, what tool can accurately explicate the intended “lobsterness” of the second element without alienating either party?

The answer is something called content. So far, our “content” consists of a spurious label (much like your typical class attribute). I think we can do a lot better:

      <h2>The Lobster</h2>
   <p>Shane is a <a href="lobsters.html">lobster</a>, which is a type of <a href="crustacea.html">crustacean</a>. He is <em>big</em> and <em>yellow</em>.</p>
   <img src="images/shane.jpg" alt="Shane sitting on the sea bed">
      <small>Photo by ajmexico</small>

The mistake we made in the first snippet was to make two items that are similar appear different. As a general rule, if two elements are of the same type and appear in the same context, then they are alike—in which case, they should appear alike. The job of styling is to make items presentable, not to define them. Only the content should be definitive, and only the tags should be used to define the content’s taxonomy.

By depriving ourselves of the class attribute, we are forced to rely on content to add meaning to our design. In our example, the background images invoked via the classes have been replaced by image tags—i.e. actual content tags that can be interpreted by both bots and screen readers (via the alt attribute). This makes the machine’s experience of the resulting design much closer to our own.

The Document Outline Link

In the example above, we showed that, even when used sensibly and sparsely, classes can undermine the parity that should be maintained between the essence and appearance of content. However, nothing is to stop us from going completely mad: we could create as many classes as we wanted, place them in whichever elements we wanted as many times as we wanted, and name them whatever we wanted.

The Divya Debacle15
Homogeneous code like the sort referred to in this strip would not be practical if we couldn’t visually differentiate between the same elements via classes. (Strip by Kyle Weems16)

This kind of freedom allows us to break with conventions that make HTML documents apprehensible and, therefore, useful. Heeding Mark Boulton’s advice about icon design would be better:

Leave “creativity” to the bad designers.

Classes enable us to represent differences that don’t really exist, but nothing is wrong with reflecting differences that do exist. In HTML5, the document-outlining algorithm17 more than ever seeks to enforce structure in an HTML document. By harnessing this structure, we can use CSS to reflect legitimate differences between the parts of our page. This requires a basic understanding of semiotics and will be the subject of the next section.

(While not necessary to understand the following section, I highly recommend Derek Johnson’s introduction to the document outline18 as background reading.)

Semiotic Style Link

View image2820 of Ferdinand de Saussure.

It would be difficult to overestimate the impact that Ferdinand de Saussure21 had on the way we understand language—and, for that matter, anything we use to elicit meaning. To Saussure, how we choose to define things is not important. Rather, their relationship to one another is truly what makes them what they are. As Saussure’s translator Roy Harris22 put it, Saussure’s contribution to linguistics was to cease viewing words as “mere vocal labels or communicational adjuncts superimposed upon an already given order of things.” If you’ve been following closely so far, you’ll appreciate why I’m a big fan of Saussure: he sees no value in extraneous classification.

Saussure’s understanding of language as a system is based on two basic relationships; the paradigmatic and the syntagmatic23. The illustration below transposes these concepts to an example of some semantic HTML.

Semiotic HTML24

Paradigm Link

A paradigm is a set of words—or, in our case, tags—with functional similarities but subtle or radical differences in meaning. In the sentence, “The crab sat next to the lobster,” the word “sat” belongs to a paradigm of alternative words that include “rested” and “crouched” as well as “stood.” It is a relationship of substitution.

There are certain rules. In English, a verb cannot be substituted with a noun, just as in HTML an inline element25 cannot always be substituted with a block-level26 one. In the diagram above, omitted members of paradigms are shown in light gray.

Syntagm Link

A syntagm is essentially a structure composed of paradigmatic choices. In English, sentences, paragraphs, chapters and books are all syntagms. In HTML, a block of code made from your choice of elements could be considered a syntagm.

Each syntagm is its own semantic system, and smaller syntagms can belong to larger ones. Just as a paragraph can belong to a chapter, so can an <hgroup> belong to an <article> and an <article> belong to a <section>.

What Am I Getting At? Link

This is all pretty straightforward stuff, so what’s the point? The point is this: The Saussurian model of language recognizes that terabytes of poems, novels, essays and plays can all be written (and have all been written) without having to invent new words or redefine old ones. If this model is good enough for natural languages such as English, then it is more than good enough for a simple metalanguage such as HTML. Of course, new words are coined over time, just as new elements are slowly introduced to the HTML specification, but this is done with careful deliberation and consensus. Classes have no such mandate.

If you really need to add a styling hook, choose something that pertains to a function, such as the role attribute. Roles are standardized and machine-readable. (View image2820.)

Meanwhile, the Saussurian model gives us more than enough scope for elegance and invention, as well as prohibits us from making bad choices. By styling the elements that make up our documents according only to what and where they are, then misleading or confusing the user becomes extremely difficult—without conscious effort. All you are doing is using CSS to expose the inherent structure of your page.

Paradigmatic styling is really just about choosing the right element for the job. There are many ways to traverse “syntagms,” so let’s look at a few examples. You’ll already be familiar with most or all of these; just imagine using this kind of styling exclusively:

  • aside h1
    A simple descendant selector that styles top-level headings that belong to asides.
  • body > div
    Styles divs that directly descend from <body> exclusively (helpful for unsemantic layout such as “wrapper” blocks).
  • p + p
    Targets all paragraphs that directly follow other paragraphs.
  • * + h2
    Styles second-level headings that do not appear at the head of their parent section.
  • section ~ article h2
    Targets all second-level headings in articles that are together preceded by a section.
  • li:nth-child(odd)
    Targets every other (i.e. odd) list item in either ol or ul elements.
  • ol li:first-child h3:before
    Styles the pseudo-content that precedes the third-level heading in the first item of an ordered list.

You will realize that any content styled using these methods will change in appearance upon being moved to another part of the page. Never fear: that is supposed to happen. Unfortunately, the employment of classes can all too easily undo this legitimate influence of context.

An Example Link

To provide an example to accompany this article, I took the step of removing all class attributes from my own blog29. The style sheet30 isn’t as neat as I’d like it to be, but that’s my fault, not Saussure’s. Note that my design is responsive and relies on a single id attribute to enable smartphone users to jump to the main navigation; however, it is not used as a styling hook.

The Importance Of Context Link

Previously, we explored how classes can be used to illustrate differences that don’t exist. By the same token, they can be used to gloss over differences that do exist.

From a semiotic perspective, perhaps the only real difference between two things that are otherwise alike is their context: the circumstances in which they are found. An English native and a French native are genetically similar but culturally different. The context of their nationality makes them, in many noteworthy ways, unalike.

Please consider the following code example:

// HTML:

   <h1 class="main-title">Article Title</h1>
      <h1 class="main-title">Aside Title</h1>
// CSS:

.main-title {

By coining the class .main-title, we have created a cypher to help us easily style all top-level headings similarly. However, the two headings in our example are not similar. Any parser that understands HTML5 will know that the h1 in the aside is, in fact, less important than the one that belongs directly to the article. How does it know this? Well, the specification mandates that asides are for tangentially related31 content, not important stuff like that found in the main body of the article. Also, the parser’s understanding of the document-outlining algorithm means that it will consider the aside’s heading as a mere subheading, belonging to the h1 that precedes it.

Context Definitions32
Google is aware that the word “context” has more than one meaning… depending on the context.View image33.)

If this is all being read and understood by the parser, then shouldn’t it also be disclosed to the user? In truth, the class in this example is redundant anyway: we could just style the h1 element with the property of font-size: 30px. The point is that if we differentiate the two elements according to context (say, by using the descendent selector aside h1), then the CSS will be bound to the HTML’s structure and the appearance of the element will fall in line with its computed meaning. In practice, by moving from an aside into the main article, an h1 would automatically look more important — which would reflect its greater importance. The aside h1.main-title selector would work, too, but the class is absolutely redundant.

Seems obvious, doesn’t it? However, popular frameworks such as OOCSS34 specifically sanction the use of classes in a way that denies the influence of context. To quote OOCSS’ GitHub page35, “An object should look the same no matter where you put it.” In fact, we’re told to avoid the descendent selector altogether, thus largely negating the “cascading” part of the technology.

The innovators of OOCSS are not the only ones who discourage the use of the descendent selector either. An article on CSS Wizardry36 reads, “As soon as an element begins to rely on its parent, and their parent, and their parent’s parent then you are doing it wrong. Your styles should never rely too heavily on where they live as this makes them incredibly unportable.”

In the next section, I’ll make the case that only content, not styles, should be portable.

Modularity And Mobility Link

An element that insists on looking the same wherever it appears is a bit like a Briton who travels from country to country refusing to speak the native language and burping the English national anthem. It’s aggressive and inappropriate.

I don’t see CSS as being object-oriented; I see it as being interface-oriented. The purpose of CSS is not to make individual items look the way we want them, but to make the interfaces that we build by styling HTML documents cogent and readable. For an interface to be optimally apprehensible, all of its components should work together politely and should respect the overall visual structure, no matter where the components come from.

Get your content ready to go anywhere because it’s going to go everywhere.

With the advent of elements such as article38, which are intended to carry content to be dispersed between documents, we should consider an approach to styling that does not permit externally sourced content to spoil the coherence of the context into which it is introduced. Once again, classes get in the way.


Unsemantic pieces of content that are styled with classes depend on the style sheets that give their particular content visual form. The class acts as a key, pairing the HTML with a specific CSS file. This has two undesirable outcomes:

  • The document that hosts the third party’s content has to load an additional resource (i.e. the third party’s style sheet);
  • The third party’s content defies the aesthetic conventions of the page and sticks out like an obnoxious advert.

By agreeing to basic semantic conventions and refusing to superimpose our own styling rules, we can instead manufacture content nodes that travel seamlessly from document to document. This approach to styling creates a scenario that allows our HTML to be interoperable40, like RSS. Website owners will maintain CSS files that style elements according only to the elements’ ownership by and proximity to other elements. Content manufacturers, meanwhile, will produce content that (by virtue of its semantic conventionality) is ready to take on the styling of any context it may enter, integrating itself with a minimum of effort.

In short, we should aim to truly separate style and content, allowing content to travel between interfaces but with the interfaces remaining unmoved. As within any properly formatted document, attribution — not aesthetics — should be what discloses the source of a piece of content.

Conclusion Link

“Roads? Where we’re going, we don’t need roads!” exclaims the inventor, Doc Brown, as his Delorean41-based time machine’s wheels fold under its chasis and the car takes off, headed for 2020. It’s a great line for its defiance: Roads, which have literally paved the way for automobile travel and made it viable, are no longer even needed. At all.

XHTML, which sought to enforce well-formed42 code, did little to enforce or cater to well-formed content. CSS classes, like the roads in Doc Brown’s line, were a costly and substandard necessity. We wouldn’t have gotten very far as UI designers without them. However, classes were only ever a polyfill43. Now that the new technology has arrived, they have become obsolete.

(al) (km)

Footnotes Link

  1. 1
  2. 2
  3. 3!/markboulton/statuses/3576335793/
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43

↑ Back to top Tweet itShare on Facebook

Heydon is a UX designer and writer interested in web application accessibility and intelligent layout systems. He gesticulates a lot and is terrible at computer games. His acclaimed book on accessibility has been published with Smashing Magazine.

  1. 1

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

  2. 2

    In the words of Tennis legend John McEnroe, you can not be serious.

  3. 3

    You’ve linked to a tweet from 2009 at the beginning of the article. I stopped reading at that point.

  4. 4

    While I have always liked the idea of not using classes on small/simple sites, like yours in the example, it’s just not practical in larger/more complex CMS-driven sites.

    I think the whole issue of content looking the same everywhere being a problem when you appropriate content from another site is a bit of a non-issue, as you would have to copy their .class CSS in order for it to NOT be styled like your content – sure their may be *some* overlap on classes, but probably not as many as you’d think. Of course, should you *want* the content you’re embedding to look like the source site, using OOCSS classes makes it relatively easy!

    Having said that, I do agree that where possible, the tools we’ve been given by HTML should be used to appropriately structure content and not over relying on CSS to “structurally style” content. Of course, given the context of a “corporate CMS” sometimes you just have to do what you can to make things look like they should in a timely manner.

    Thought provoking for sure, and sensibly achievable for a small/simple site with one/few devs, but I think I’ll be sticking to classes for styling my more complex sites.

  5. 5

    Ricardo Magalhães

    June 19, 2012 3:16 am

    Matt Andrews said it all. The whole idea behind it is very appealing, but nowhere near of being possible in the real word. And by real world, I don’t mean our personal blog or single page portfolio. I mean the world where you have to work with a team, know what to expect in the front-end side, and be ready for design changes on the spot which require markup to be changed.

    For instance, we still need a lot of wrapper elements in divs, sections, whatever. Some overly specific CSS targeting could kill your entire styling just by adding this necessary extra element that the client insisted on having at the very last minute. And that’s just too much work when you’re on the spot. I like the reassurance of knowing that if I need to add an entire block of something else, my styling rules will not break. With your approach, hell would break lose.

    We need to build with a modular and scalable frameset, otherwise we’re just asking for trouble in the long run.
    I agree with you in the sense that we shouldn’t cultivate a ‘classitis’ workflow, and not everything needs to be a reusable element on its own. The trick lies in knowing where the middle ground is.

  6. 6

    Trolling published as link-bait.

    Try building something bigger than a brochure site without using classes and you’ll quickly learn the error of your ways.

  7. 7

    Stephen Melrose

    June 19, 2012 3:25 am

    My problem with your argument is, frankly, that you don’t make it very well. You have some good points, but most of them are completely unrelated to your actual argument and are just waffle in this tirelessly long article.

    I think I can sum up this article in a couple of sentences,

    “Don’t use classes to define content. The *context* of content is what defines content.”

    That about right? The problem with your argument is that the limitation of what is considered valid HTML does not allow you to do this, therefore, we have to use classes to *enhance*, not define, content.

    Also, I would genuinely love to see you code up a big, corporate, CMS managed website without classes. In fact, I extend to you that very challenge. And if you succeed, I will completely rescind my argument and declare you the victor.

  8. 8

    Stop Using Drupal???

    Due to Views module markup??

    Semantic View + Semantic CCK… and fears become small!

    Platform is not a problem… but the way you use it…


  9. 9

    Oh okay, yeah I really do respect people who have enough time to search twitter for out-of-date information. And then use it to misinform everyone else.

  10. 10

    One of the problems with this article is that it sees classes as mere styling-hooks. While CSS has a big impact (especially today), classes (and ids) are there for all scripts. They divide your site in logical, portable components that could be used wherever on your page/site.

    If tomorrow the Analytics guy passes by and asks you to track all the clicks on “read more” links in news article teasers across your site, you need to be ready. Without the proper use of classes and ids you won’t get anywhere.

    Apart from that, I’d love to see a use case for a 10-template site using this idea. I don’t think you’ll get very far, unless you keep your design very slim (and thus highly dependent on your method of working).

  11. 11

    People slamming this article as being not attached to the real world only read the title.

    This article was extremely thought provoking, and has caused me to think much more about why and how I do things. It’s these types of articles that push our profession forward.

    Before slamming something, at least try to implement some of the ideas presented an come back in a few weeks with a proper rebuttal with some annecdotal experiences for us.

  12. 12

    You declare that one should stop using Drupal, and then proceed to link to a tweet from Boulton that are dated back to ’09? Nice.

    Views is easy to adjust to whatever truth you want.

    Also: It is very easy to style Drupal the wrong way, but it’s also powerful in the way it enables clean, well-targeted CSS. Yes, the standard markup is dreadful, but it’s your job to make it lean. It works out-of-the-box as it should, and can be molded to fit whatever reality you want it to.

  13. 13


    I do not believe that you have afforded this topic so much thought and managed to arrive at the conclusion that classes are redundant.

    I would go as far as to say that had you worked on large project that demands a scalable modular css architecture you would have been unable to arrive at these conclusions.

    I normally attempt to implement ideas such as this before offering a response. However as I have been considering this topic throughout my career I feel I am well placed to offer an instant rebuttal on the back of experience.

    Specificity wars, lack of maintainability, just a no.

  14. 14

    Heydon Pickering

    June 19, 2012 4:02 am

    The Sizzle selector engine does not rely on id or class attributes.

  15. 15

    I suspect Heydon is playing devil’s advocate to a certain extent. I can’t imagine he would attempt this on anything larger or more complex than his personal blog (correct me if I’m wrong). However as a concept it is very intriguing.

    Although I wouldn’t go so far as to avoid classes altogether I can see the logic and benefit of keeping them to a minimum. How many times have you seen:

    <article class=”product”>…</article>
    <h1 class=”product-heading”>…</h1>
    <img class=”product-img” />
    <p class=”product-description”>…</p>

    I don’t see why you can’t get rid of all classes except .product and then use descendant selectors for the product module. This way you achieve the best of both worlds.

  16. 16

    Stephen Melrose

    June 19, 2012 4:06 am

    Most, if not all, selector engines don’t *rely* on id or class attributes, they merely support them, like any other selector syntax.

  17. 17

    Heydon Pickering

    June 19, 2012 4:06 am

    I just checked. Drupal is still rubbish.

  18. 18

    The ambition of this article is awesome! Having said that I can’t quite bring myself to agree…

    I think there were two points which I am 100% behind (actually only alluded to in the crustacean example)
    1. Don’t use classes to give your content meaning.
    2. Have meaningful content.

    Which, yeah, sounds good!

    I just don’t see what this means you *shouldn’t* use any classes though. Since all classes are “decorator classes” why can’t we use them for decoration? The idea seems to be that each piece of content should be visually distinct and that doesn’t sit well with me. To me that’s like an interior decorator saying your armchair and sofa shouldn’t look the same. Of course the shape is different, as is the context; but I want both in a luxuriant orange zebra print! Of course the armchair in my study should be a rustic brown leather, just like the bar stools in the kitchen-diner and the sofa in the den.

    Let’s assume all users (human or bot) can understand all these items of furniture. That is: what they are, how they function, etc. All I need to do now is ‘add the fabric’. This is the exact purpose of classes. If I only had one sofa, sure maybe I don’t need a .zebra-print class. Actually let me correct myself – I probably never *need* a class; but I should use one here. It will make my life easier with no detrimental effect.

    To push the example further: what if I have two armchairs in my den but I want these to be upholstered differently? The purpose is the same but just for kicks I want them to look different. So I know they are both in the and they are both ‘s. So that’s easy right? I’ll just do den > armchair + armchair { whatever }. Sweet, done! But what if I remove (delete) the first chair? I could use last-child, but there is that pot plant… So last-of-type? Now I can’t add more chairs. It’s starting to get confusing… I’m left with 3 choices:
    1. Use a class
    2. Try deal with the problems as they arise (i.e. fancy selectors)
    3. Live with matching armchairs

    The order of these is not random – the first option is clearly preferable. Option 2 will be what the client/designer pushes. Option 3 will lead to a very dull web indeed….

    Now let’s say I’m worried about syndication. Let’s say someone gets hold of my html classes and all. Getting a class of .zebra-print is not going to adversely affect them. They can quite happily strip this and ‘re-upholster’ it – as you might do when you get a second-hand sofa. If they don’t want to strip the classes, that’s their problem. My content is meaningful enough for them to do so and, therefore, they must be choosing not to.

    I really do applaud this effort; I think it’s great to push the boundaries and get people looking at the issues differently. Additionally your argument, although flawed, is very thorough and eloquent; so seriously, thanks for going out on a limb and writing this!

  19. 19

    I don’t rely on the phone to communicate but it’s a hell of a lot better than traveling to the other side of the country when I want to talk to my friend.

  20. 20

    My trash fueled flux capacitor is now at maximum charge thanks to this post. See you in the Future!

  21. 21

    Don’t let the door hit you on your way out.

    Even if the article here was written by Justin Bieber on meth and arguing about why we should put peanut butter in our shoes, your reason to “stop reading” would still be far more ridiculous.

  22. 22

    Heydon Pickering

    June 19, 2012 5:52 am

    Not quite. My argument is that classes do *not* enhance content; only its appearance. This is true of all CSS but, in the case of classes, there is no obligation to the semantics of the page.

    I think that it is self-evident that a larger volume of content does not render this false.

    Feel free to recommend me to your corporate clients. There’s absolutely no reason content should need to rely on class-attributed markup just because it is managed. Structured content is well managed content and needs classes least of all.

  23. 23

    This article reminds me all of the elaborate theory that I learned in college but have yet to experience in the real world.

    That also reminds me – we live in the real world.

  24. 24

    I tend to agree with the w3c best practices on classes:

    The biggest issue with CSS objects is that they are directly coupled to HTML making layouts incredibly inflexible. Remember CSS Zen Garden? All the same HTML with no layout classes made the layouts incredibly diverse using only CSS. This has been irrelevant for the most part until responsive web design became so popular. Now we need this flexibility again to change layouts at different screen sizes and device capabilities, layout classes are getting in the way of that.

    To give OOCSS and SMACSS credit they solve very real language issues with CSS itself. In order to build sites at scale styles need to be abstracted into smaller shared objects. They do this by containing these objects in classes. The issue is that there is no way to execute these objects within CSS. If CSS had a feature like Sass @extend or @mixin developers would be able to adequately write and execute objects within CSS and retain the much needed flexibility and semantic markup, even at a large scale.

  25. 25

    Some people get paid by the word.

  26. 26

    I can definitely agree to that, the era of “classes for semantics” is clearly in the past. That doesn’t mean they’ve become obsolete though, they’re just adapting to a new function.

  27. 27

    The only advantage of this article is to make us think and debate. But the conclusion is : continue to use classes guys.

  28. 28

    Heydon Pickering

    June 19, 2012 9:27 am

    By not defining styles via classes that are manifest in the markup, necessary change is actually easier to achieve.

    Otherwise, you could be left with a bowling alley with a sign that reads ‘wig shop’.

  29. 29

    Heydon Pickering

    June 19, 2012 9:29 am

    Tell the Photoshoppers “no”.

  30. 30

    This article is terrible. The crux I got was, don’t use class names in conjuction with CSS for styling but, that is exactly what CSS is for!

    As has been touched on in previous comments, building anything more than a brochure site without classes is nigh-on impossible. I’d love to see an example site from the author where he’s not used classes, as otherwise this is just pie-in-the-sky speculation and published just to bait the web community.

    It’s alright specifying the look of an article and a heading within an article, but then how do I differentiate styles for different types of articles, i.e. a news feature and a video item, which may both be marked up in article tags, but one I may want a green background on and the other a blue background? You’ve guessed it: I’m going to use a class name.


↑ Back to top