Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

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

Further Reading on SmashingMag: Link

It’s Not About Maintainability Link

In her recent presentation “Our Best Practices Are Killing Us6,” 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:

  • Consider a different client,
  • Consider a different career,
  • Stop using Drupal.

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 classes, 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 label7
View image8.

CSS classes9 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 frameworks10 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. Mike11. 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 microformats12 (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 Tanguay14 and ajmexico15)

  • 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 specification16 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 Debacle17
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 Weems18)

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 algorithm19 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 outline20 as background reading.)

Semiotic Style Link

View image2922 of Ferdinand de Saussure.

It would be difficult to overestimate the impact that Ferdinand de Saussure23 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 Harris24 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 syntagmatic. The illustration below transposes these concepts to an example of some semantic HTML.

Semiotic HTML25

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 element26 cannot always be substituted with a block-level27 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 image2922.)

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 blog30. The style sheet 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.

<abbr=”Extensible HTML”>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
  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 designer, writer and public speaker. He works with The Paciello Group as a UX and accessibility consultant. His book, Inclusive Design Patterns, is available in hardcover and as an ebook from Smashing Magazine.

  1. 1

    Matt Andrews

    June 19, 2012 2:40 am

    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

    Leon Kessler

    June 19, 2012 3:10 am

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

  4. 4

    Luke Scammell

    June 19, 2012 3:13 am

    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

    Mark Simpson

    June 19, 2012 3:21 am

    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

    Leon Kessler

    June 19, 2012 3:46 am

    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

    Niels Matthijs

    June 19, 2012 3:46 am

    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

    Luke holder

    June 19, 2012 3:47 am

    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

    Rasmus Kalms

    June 19, 2012 3:50 am

    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

    Thomas barber

    June 19, 2012 3:58 am


    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

    Mike McCabe

    June 19, 2012 4:06 am

    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

    Thomas Griffin

    June 19, 2012 5:57 am

    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

    Scott Kellum

    June 19, 2012 5:59 am

    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

    Niels Matthijs

    June 19, 2012 6:15 am

    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.

  31. 31

    Web components (the emerging standard) provides a great platform for using Heydon’s approach, while also nicely handling your concerns. With modular components and scoped styles, selectors are very well contained and your component design can scale beautifully up to very large and complex sites and apps.
    A good lot of it is available now in Chrome Canary, and parts are starting to be developed in Firefox. The +Web Components page has more.

  32. 32

    Enrique García

    June 19, 2012 3:17 am

    Do you have any evidence that this way of doing CSS is feasible on anything but trivial webpages, or is this all speculation?

    If not, why don’t you make like a tree and get out of here? (and come back with some evidence later)

  33. 33

    Mark Simpson

    June 19, 2012 3:24 am

    Should have given you even more reason to read. Have you any idea how hard it is to find a tweet more than 2 days old?

    Takes some serious skill.

  34. 34

    *I think* what you’re trying to say is that in structuring our content in better, more meaningful ways that we can reduce the reliance on classes? The very structure of our content would make them unique and portable and that by using selectors to style them based on their “context” we could control how they appear when not in their typical setting?

    That’s all well and good but would what you’re suggesting would be near unmaintainable in the event of changes to containing structure.

    You also don’t seem to account for the dynamic nature of websites. Classes are essential for indicating “states”. You can chain classes to extend the module/pattern/component and thus reduce the amount of code you need to write and maintain.

    I think you’re missing the point of methodologies such as OOCSS. I recommend you give Mr Snook’s “Scalable and Modular Architecture for CSS” (SMACSS) a read: – I think you’ll really like it. He talks about using certain context based selectors to help reduce the need for classes and control the “Depth of Applicability”, etc which I think is along the lines of what you’re getting at?

  35. 35

    Martin Chaov

    June 19, 2012 4:08 am

    Well … I was about to tear him apart but you already did it…

  36. 36

    This has to be one of the most mis-guided articles I’ve read in years. The author clearly has no concept (or practical knowledge) of creating complex online applications.

  37. 37

    Niels Matthijs

    June 19, 2012 4:13 am

    Sure, but how are you going to differentiate between different components with identical html structures?

  38. 38

    Aaron Devik

    June 19, 2012 4:20 am

    “Stop using Drupal” – In other words, stop using anything that you are too lazy to investigate on how to make the output better. (And yes, even with Drupal it is possible to output whatever markup you want).

  39. 39

    If you don’t take this article too literally it makes sense to carefully look at how you are using classes to style content and reduce classes on structural elements where possible. I’ve inherited many web applications over time that have gathered lots of css cruft where different developers have refactored content and hacked around the associated css to try and accommodate change – Time and time again I’ve inherited things like mis-named classes (‘outerContainer’ on a div that’s inside an ‘innerContainer’), and elements with a class like ‘hotRedBackground’ where: .hotRedBackground { background-color: yellow;}

    It’s common sense really, eliminate classes on structural elements where possible, keep them on discrete ui widgets (buttons etc), and use either Sass or Less to make mixins for re-use. Also, they still may be necessary if you’re adjusting styling in response to dynamic behaviour using jQuery’s toggleClass/addClass etc.

  40. 40

    Heydon Pickering

    June 19, 2012 1:25 pm

    I wholeheartedly recommend using microdata etc to add semantic meaning to your markup and even to use semantic microformat-like classes as styling hooks. Why? Because these classes pertain to computable differentiation.

    Why would you want to style the second article differently with a class or otherwise? What is the case?

  41. 41

    Heydon Pickering

    June 19, 2012 1:27 pm

    I’m not saying (nor did I say) that classes are sub-optimal. I’m saying they are not fit for purpose.

  42. 42

    Leon Kessler

    June 19, 2012 4:34 am

    Fair enough then, as long as you actually checked.

  43. 43

    I agree that throwing a new class name at every styling issue is not the right way to do things. But your highlighted comment right here is a nice example of something I find impossible to implement without the class attribute. How would you propose, in a list of comments, to visually distinguish the ones made by original post author without resorting to something like class=”bypostauthor”?

  44. 44

    Aside from the flaws in this, summed up very well by the top comment, I was quite taken aback by the 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.

  45. 45

    great Quoting mark on a tweet thats 3 years old… *coughs*
    Before you lash out please learn the cms you attacking, im not expecting you to understanding how Drupal, views & the theme layer actually works (it can be a pita) but i can point you towards the Semantic views module (or just read views documentation) or take the mothership theme for a spin ;) … its not that hard actually.

  46. 46

    Heydon Pickering

    June 19, 2012 1:51 pm

    I’m perplexed. It enabled clean, well-targeted CSS but its standard markup is dreadful? Why isn’t the standard markup clean? Surely that would be less work?

  47. 47


    June 19, 2012 5:12 am

    I can only guess this post is one of two things:

    1 – the author still believes that “any publicity is good publicity” and has posted an intentionally inflammatory post that makes no real points, but rambles a lot (to give the impression of thought going into it), strictly to drive hits / get his name out.

    2 – this is a parody post, authored in direct response to the opposite (equally misguided) extreme of “no ids, ever” being supported by some (not all) users of “OOCSS”.

    We get it, kids – you’re trying to make your mark and do something “different”. Sometimes different isn’t better – it’s just different. Or worse.

  48. 48

    Wait, the trolls have been elevated to writing articles these days, rather than comments?

    I’m sure the article makes some good points, somewhere, but the Drupal FUD, and the exaggerated “Never ever use classes ever” approach removes any credibility.

    Bravo sir, great trolling. :-|

  49. 49

    Heydon Pickering

    June 19, 2012 2:28 pm

    Thanks for your considered reply, Matt.

    Firstly, I don’t see why any website should demand more than 2 or three basic layout templates. If they do, however, it will ultimately be the markup structure that informs the visual layout. In other words, context is still your friend.

    With selectors like section ~ article h2 there is less pain when I want to refactor. All I have to do is move the content away from its current position and the styles correct accordingly. I only want articles that are preceeded by a section to look a certain way. It is where they are that informs my styling decision.

    There is no reason why sites that forego classes should look boring. That assertation demonstrates a profound lack of imagination. I use the following analogy in more detail further down in the comments, but think of HTML elements as Lego™ bricks. The types of brick are finite, but this poses no limitation to our creativity. The combinations are near-infinite.

    CSS is not supposed to be modular. You are thinking of HTML. HTML is designed to be modular and CSS has been innovated to describe it visually. By misapprehending CSS as an object orientated programming language in its own right, you undertake the task of maintaining 2 potentially disparate sets of objects / modules when only one is pertinent; that of the HTML.

    The cascading feature of CSS is based on specificity and inheritance. This provision should help you style documents if you choose to respect their own modularity. By dividing your styles into individual, isolated components / modules of their own, you are no longer harnessing the cascade to its fullest extent. OOCSS is a better use of classes, not a better use of CSS.

  50. 50

    You need classes (at least) for states like:

  51. 51

    So what you’re saying is: since when can a weatherman predict the weather, let alone the future?

    Continuing your point, a lot of the examples given are against best CSS practices of efficient selectors.

    Heydon’s “nudge-right” class example is rightly embarrassing, but there are plenty of proper uses of “semantic” class selectors. They may not convey meaning to search engines and bots, but they are meaningful to the designer/developer that is incorporating them into a document structure.

    It’s consistent use of those conventions that results in the new semantic tags that he discusses. Someone recognized that div’s with class or id=”header” were common enough to create a dedicated tag. So I see this behavior as productive, as consensus in implementation helps evolve new semantic tags of the future.

    Discussed in other threads: I can’t speak much towards the output of Drupal, but the WordPress templates and engine utilize lots of *structurally* meaningful class selectors that can be styled against in a modular and reusable way. Take a look at the default output for posts or sidebars/widgets and you’ll see what I mean.

  52. 52

    Tom Giannattasio

    June 19, 2012 5:46 am

    Have you ever asked for directions? Which is easier?

    1. (contextual directions) Go past the bocce ball court and turn left in front of Milfred’s Wig Shop. If you pass the third Starbucks, you’ve gone too far.


    2. (explicit directions) Go up to Market Street and turn left?

    Roads are named for a reason. They’re shortcuts that help humans find their way. In a small town of only a few roads, you could probably do away with explicit naming and rely on context. If you’re building a city, however, you need more sophisticated wayfinding. Context works for those who fully understand the scope, but is meaningless to those who don’t.

    I don’t know about you, but I want to build cities.

  53. 53

    My dealings with Drupal were fairly recent, but I don’t know how many of the issues I dealt with were created from bad theme design that broke standard behavior. I have lots of other issues with the platform, primarily the drastic changes between versions that break compatibility with the previous generation of modules.

    Unless it’s part of the core, you really can’t get comfortable with any solution because there’s no guarantee that you’ll be able to continue using it a year down the road.

    While much of that is off-topic, it’s not as much as you would think:
    The Semantic Views module you suggest was also published in 2009. The Drupal 7 module doesn’t seem to be finished yet, but development ceased in February 2011.

    I don’t think the Drupal community is very healthy, and that alone is a reason to be wary of its use.

  54. 54

    Adrian Simmons

    June 19, 2012 6:18 am

    Two points.

    Others have already pointed out the difficulty of doing this in a large cms, part of the reason is that admin users can easily change the context of content. Context is not always reliable.

    Secondly a large number of sites are still built using the admittedly crappy and broken photoshop first workflow. Those designers just lurve changing the appearance of content seemingly at random on different pages – where the only context is the URL, again, an unreliable context to use for styling.

  55. 55

    Kevin Wilde

    June 19, 2012 6:43 am

    Sorry in Back to the Future 2 they were headed for 2015 not 2020.

    Also, I completely disagree.

    Good day to you sir!

  56. 56

    It felt like the author got way too caught up in the expression and delivery of their concept to actually realise it is completely detached from real world solutions. A nice idea is all fine and dandy, with fancy sub-headings, movie references and quippy photos, but doesn’t mean it’s a practical one.

  57. 57

    Brian Fryer

    June 19, 2012 6:53 am

    “In English, a verb cannot be substituted with a noun”

    I beg to differ. You should Google it.

  58. 58

    Heydon Pickering

    June 19, 2012 7:27 am

    Users don’t use classes as signs. They can’t see them.

    (1) Uses more explicit labels than (2)

    (2) implies that I don’t require context to know where Market Street is. This is not true. “Go up to market street? Where’s Market Street?”

    There is more than one Market Street in the UK. Many towns with markets inevitably have ‘Market Streets’. Which town (read:context) am I in?

  59. 59

    Matt Andrews

    June 19, 2012 7:27 am

    This is a great analogy. It’s like using Google Streetview for navigation versus using the actual map. You might arrive at Mildred’s Wig Shop to find it’s been converted into a bowling alley. Are you on the right road? Maybe Mildred’s is back on that last corner…

    The only way this type of direction is helpful is in a world where nothing changes, or you control every change (so you’re a town planner, or God).

  60. 60

    “Wait, the trolls have been elevated to writing articles these days, rather than comments?”

    I’m sorry this made me LOL.

    Yeah this would be a great April 1st article. I like agree with the basic premise that “content is king” – anyone in SEO could acknowledge this axiom, however the “king” still needs his loyal subjects.

    While we are making websites for robots and humans alike, we are still humans and not robots – so anything that is legitimate and provides us with anther way to scale our work load designing and maintaining large, complex websites (ecommerce I’m looking at you) needs a second thought before it gets tossed out for purism.

  61. 61

    Heydon Pickering

    June 19, 2012 7:44 am

    I think you need to reread my conclusion.

  62. 62

    Heydon Pickering

    June 19, 2012 7:51 am

    That doesn’t mean it is an impractical one either.

    Here is an example of a real world problem solved by not using classes: You no longer have to write classes onto your HTML tags. Rejoice!

  63. 63

    Tom Giannattasio

    June 19, 2012 8:00 am

    1. I’m speaking to the fact that actual humans need to interact with markup. The end user could care less how something is put together as long as it works.

    2. Your technique may work on small sites that you, yourself build. However, that all changes when working on a larger scope with a team that could be scattered across the globe.

    3. Of course context is needed for directions to work. You’re arguing against yourself here. Put “Market St” into Google Maps and you’ve narrowed things down more than putting in “street”.

    The point is that classes add understanding… for humans. It’s impractical to require someone to understand the entire scope of a site to tweak a single element.

    A final note: the class selector is far more efficient than some of the shiny, new selectors. You’re actually doing the end user a disservice by relying on them.

  64. 64


    June 19, 2012 8:22 am

    No, he read it. You just came to the wrong conclusion, so he’s discounting it.

  65. 65

    Heydon Pickering

    June 19, 2012 9:22 am

    What is the new function, Niels?

  66. 66

    Enrique García

    June 19, 2012 9:26 am

    > So what you’re saying is: since when can a weatherman predict the weather, let alone the future?

    I’m just saying that exceptional claims require exceptional evidence, and I don’t see you providing that.

    Heydon has made a pretty outlandish assertion. I would expect it to be backed up with a strong evidence.

    To make it more clear: Nicole Sulivan’s has proven that OOCSS works in the real world. Applied to Facebook, there was a big decrease in CSS & HTML size, as well as an increase in code maintainability. Heydon claims that css classes, which are the base of OOCSS, are … “suboptimal”, and he’s got a “more adequate” way of doing things.

    So I’m asking: has this “more optimal way of doing things” been field-tested in a realistic environment, or is this just a theoretical thing?

    I’m not saying that “weathermen can not predict weather”. I’m saying that there’s already weatherwoman out there who predicts weather very well, and this other weatherman claims that he knows better. So I’m asking him: “ok, what will the weather be?” *If* I get a forecast, then I’ll compare his answer with Nicole’s and I will decide. Until then, for me, it’s all words.

  67. 67

    Congratulations, you’ve just discovered the reasoning behind RDFa and microformats! :)

    If you have multiple articles, where you want the second one styled differently, and you use `:nth-child(2)`, you’re damned – who said it will always be the second child of some parent? This would quickly become a train-wreck in any project.

  68. 68

    Bruno Abrantes

    June 19, 2012 10:43 am

    Your example is perfect to show the error of the author’s ways. Without classes or other markup differentiators, this feature would not be implemented. I don’t like it when excessive zealotry affects a design so drastically for such a low return as the “purity” of HTML content.

  69. 69

    Maybe I didn’t read it properly, but it appears to be a long-winded way of saying: put as much meaning as possible into the markup (structure), don’t just paste css classes on everything, instead try to use selectors that work on the structure itself. Which is a perfectly good point, of course. To counteract my being so condescending or ignorant, I applaud the author for the crustacean example. In particular, I am very fond of the crab’s and lobster’s names. »’Ello, crab, what’s yer name?« »It’s Mar’in! What’s yours?« »Nice to meet ya. Shane.«

  70. 70

    BTW the weatherman comment was another Back to the Future reference following the “make like a tree” and “Where we’re going” comments. ;)

  71. 71

    Heydon Pickering

    June 19, 2012 1:30 pm

    I agree. CSS Zen Garden is a good example. Thanks

  72. 72

    Heydon Pickering

    June 19, 2012 1:33 pm

    I’m assuming from the ‘open’ class that you are writing a web application, not laying out content. In which case, it might be an idea to put your application in a div with role="application" to warn screenreader users.

  73. 73

    Heydon Pickering

    June 19, 2012 1:41 pm

    Despite expressions like “explicate the intended lobsterness”, I am quite serious.

    What I am suggesting is better in a number of demonstrable ways. I refer you back to the article.

    Also, I am not a conglomerate of children.

  74. 74

    Heydon Pickering

    June 19, 2012 1:44 pm

    Every element on the page is necessarily unique in terms of context. I also recommend using the role attribute.

  75. 75

    Heydon Pickering

    June 19, 2012 1:46 pm

    Er, yes, but you are missing my point. With such selector engines, the argument that classes and ids are valuable for scripting is not as valid.

  76. 76

    Heydon Pickering

    June 19, 2012 1:49 pm

    Or you could add actual meaning by using microdata:

  77. 77

    Heydon Pickering

    June 19, 2012 2:00 pm

    If you assume that I have never worked on a big project and you assert that the error will only be disclosed on doing so, then where have I gone wrong?

  78. 78

    Niels Matthijs

    June 19, 2012 2:37 pm

    Providing the necessary hooks for whatever script runs across your pages (including css and javascript). And even though these class names don’t need to be “semantic” anymore, it makes it a lot easier to provide the right hooks.

    No matter what you do, in the end you want to target certain components based on their identity. For example, structurally/tag-semantically a news item and event item can be identical, yet for all kinds of reasons it’s important to be able to differentiate between the two.

    In your crab example you’re using xml tags rather than html tags, which clearly isn’t the right way forward either, so I wonder what you’re proposing as an alternative?

  79. 79

    Heydon Pickering

    June 19, 2012 2:44 pm

    I use a CMS called Perch quite often. There are no limitations (within reason) to how much content I can serve using it, nor are there any limitations whatsoever to the number of content types I might wish to spawn. The markup for the structured content that manages the various content types is defined by me and only by me, the developer, and I can use as many or as few classes in this markup as I wish. Of course, since it’s me, I wouldn’t use classes but I might consider adopting some microdata. Then again, I’m crazy.

    The Perch CMS contains classes. I don’t care: that’s in the CMS and they have the decency to keep the CMS and the public site separate.

  80. 80

    Danny Moerkerke

    June 19, 2012 11:48 pm

    While I’m not sure I would ditch classes completely, I don’t see why this approach would NOT scale. And what exactly would be the problem to apply this to a CMS driven website? Does the WYSIWYG editor in your CMS output markup with classes? I doubt it.
    I think the author definitely has a point and I also believe this approach is closer to how CSS was originally intended. OOCSS is not a bad idea but it feels like implementing class-based inheritance in Javascript, which already has prototypical inheritance. It’s a bit like using a tool in a way it was not intended.
    Making good use of the cascade in CSS is closer to the OO principle of inheritance than OOCSS with classes. And just like OOP, using CSS in the way the author describes requires some more planning and thought upfront, but that doesn’t make it impossible.
    I would love to see some real-world examples of CMS-driven websites where this approach would be “impossible”. I suspect the real problem is that such a website is already crippled by too many classes and inefficient CSS.

  81. 81

    you can’t always tell them no. actually most of the time you can’t tell them no. you’re just a code monkey and no one sees what you do, so no one cares.

  82. 82

    Heydon Pickering

    June 20, 2012 3:01 am

    Surely a more complex, unweildy CMS makes working with large teams and third parties more of a headache.

    What sort of content necessitates a CMS that is difficult to use and why would it have to output unsemantic markup?

  83. 83

    Heydon Pickering

    June 20, 2012 3:59 am

    So, the fact that I reengineered my blog as a case study to accompany this article is not good enough for you?

    Sorry, it’s a new technique and I have not had the opportunity to use it for many clients.

    Meanwhile, I found the following inside a class attribute of a div on someone’s blog:

    builder-module-outer-wrapper builder-module-navigation-outer-wrapper builder-module-before-content-outer-wrapper builder-module-after-image-outer-wrapper default-module-style-outer-wrapper default-module-style-outer-wrapper

    Do you think it is an example of Object Orientation or are they using FrontPage?

  84. 84

    Luke Scammell

    June 20, 2012 4:38 am

    Touché! I wouldn’t say it’s either a good example of OOCSS or using FrontPage, I’d say they probably haven’t gotten around to creating a decent site for themselves yet because they’ve been too busy with life, the universe and everything – probably.

    They’re probably testing various different things and should give up doing that on their blog and actually create something half decent, using their actual dev sites for testing – again, probably ;)

    No, I don’t think your blog is a good example as it is a small, simple site. Show me something like the Sky Sports site using this technique.

  85. 85

    Heydon Pickering

    June 20, 2012 4:47 am

    The Sky Sports website should not exist at all :-)

  86. 86

    Extremists at either end of the debate (“No classes, ever!” vs. “CLASS ALL THE THINGS!”) are being.. well.. extreme

    I think there’s room to consider the best approach on a case-by-case basis.

    Personally, I believe that a clean mix of classes (where “required”, rather than on “all the things”) and hierarchy-based selectors works best for the majority of projects.

  87. 87

    Heydon Pickering

    June 19, 2012 10:58 pm

    I’m glad you liked the article, Martin. CSS is not for using classes in conjunction with CSS. That sentence does not make sense.

    My website does not use classes. It is a CMS-driven blog. In addition, it only uses one stylesheet, no images and no javascript.

    It is nigh-on impossible to style a large website without classes if you plan the content, and therefore the markup, badly.

    Attribute your video items with microdata. The pattern is standardised:

  88. 88

    Heydon Pickering

    June 19, 2012 11:16 pm

    The ‘real’ world is what we make it. You are a cynic :-)

  89. 89

    Heydon Pickering

    June 19, 2012 11:18 pm

    You are incorrect. I am fully aware that I have to ‘customise’ Views to make the HTML output bearable. That is why I don’t like Views: Clean markup necessitates reverse engineering.

  90. 90

    Heydon Pickering

    June 19, 2012 11:23 pm

    You only know how to use a phone at all by convention. The numeric keypad and its configuration adheres to a standardised pattern. Had the manufacturer decided to impose its own interface rules you would have to learn their new idioms before you could make a call.

    Annoying right? That’s how people using screen readers feel when they encounter a rat’s nest of divs that are only coherent by eye due to superimposed classification rules.

  91. 91

    Heydon Pickering

    June 19, 2012 11:24 pm

    Despite what many commenters are supposing, I do work on large projects, in teams on CMS driven (or usually data-driven) applications. Naturally, most have used classes.

    Using classes to style the UI on these projects is necessarily problematic because classes constitute an added layer of complexity and an entirely additional lexicon. This lexicon of invented terminology must be deciphered for team members whilst virginal tags, arranged semantically, are understood by any educated developer. Even one you have not met.

  92. 92

    Heydon Pickering

    June 19, 2012 11:44 pm

    The nightmarishness of the maintenance of the website (and its styling) in question is largely proportional to how well-structured the markup has been made. OOCSS is not the better solution, it is the better solution if you are not dealing with or care about semantic HTML.

    Refactoring a site with unsemantic markup is much easier if you have employed OOCSS. It is easier still to refactor a site that does use semantic markup. Why? Because the markup itself dictates the modularity of the content and the styles fall in line with these structures and components.

    I have worked on large scale projects, in large teams, for companies whose offices are not in my country. The application of classes added complexity and reduced clarity. This is inevitable since classes constitute an entirely additional lexicon of ciphers for the styling of content. I would not have had to continue to rely on classes as the project progressed if I had specified the structured content better.

  93. 93

    Heydon Pickering

    June 20, 2012 12:39 am

    I really don’t get the scaling problem lots of commenters are offering either. How does the advent of more content or even more types of content necessitate unsemantic markup? Or the use of classes with semantic markup??

  94. 94

    Heydon Pickering

    June 20, 2012 12:47 am

    Putting peanut butter in shoes is fine for small popstars but is it really a scalable methodology?

  95. 95

    I couldn’t agree less when it comes to Drupal, but this was still a refreshingly good opinion piece, and a very well-written one at that. To a measurable extent, though, I have to agree with Matt Andrews (even after reading your reply).

  96. 96


    June 20, 2012 2:08 am

    You have demonstrated absolutely nothing. If this were any type of peer-reviewed journal, you’d be laughed at.

    You’ve made a bunch of spurious claims with no factual evidence behind them (hell, even anecdotal evidence would be useful).

    The entire article reeks of “you’re all doing it wrong, and I’ve finally figured it out”, except all of your claims are half-baked.

    I still stick to the “outrageous statement made for the purposes of hit-whoring” assessment.

  97. 97

    Classes, first of, are not “CSS classes”. Nor is their purpose to solely be used in “selectors” for styling or scripting. A “class” is exactly what it says – a “class”, i.e. a method of classification. If you don’t feel that you should classify your “elements” – well – don’t. However, classes and classifications are needed. Semantic or visual – doesn’t matter – as long as you have more than several similar items, you can already group (classify) them into smaller groups.

    As for using various semantic and visual classifications as styling hooks – it all depends on situation. You might have different types of content inside a “p” inside an “article” – all being the same level in the DOM. You need to distinguish between them. You might want to style quotations from books differently than quotations from newspapers. You need to have different style for “paragraph text of an advertisement” compared to “paragraph text of a blog article”. Some items need to be styled the same regardless of context. Some items need to be styled differently regardless of being in the same context. Classes allow us to define these.

    And last, but not least, DOM order defines DOM order. It does not define the visual semantics nor should it. Ever heard of “separation of concerns”?

  98. 98

    Luke Scammell

    June 20, 2012 2:52 am

    The key points here are that it’s controlled by you and only you and that Perch appears to be “a really little content management system” – so not big, unwieldy and complex.

    Now work with a set of 3rd party developers and something like the Sitecore CMS and see how it works for you.

    As I said, with small or simple sites and as others have mentioned, when you can control everything, your method can work just fine. As soon as your complexity starts to go up through with both site and team sizes, or even multiple teams, it just isn’t practical any more.

  99. 99

    Interesting article. I find myself somewhere between agreeing a bit, and disagreeing with you completely.

    First of all, “OOCSS” was not some huge revelation for me. In my opinion the practice of writing good, efficient, DRY CSS comes naturally to anyone over time, and it doesn’t necessarily have to look like “OOCSS” and be reliant entirely on classes.

    However on the issue of having certain things which will insist on looking the same everywhere, I simply cannot accept that this is aggressive and inappropriate. This is often what we want.

    I would go as far as to say I get a sense of pleasure when I don’t use a class. In doing this, occasionally I make use of most if not all of the CSS3 selectors you pointed out. Result? I feel as though I’m wielding much more power in my stylesheets. Importantly, “power” !== “control”, and power without control can be dangerous.

    Even when you have the supposed control and security of context, this is no guarantee. Using a class, solidifies the expectation that any contextual selectors you use for a given element will behave the way you intended.

  100. 100

    Luke Scammell

    June 20, 2012 3:06 am

    Please give some actual examples of these large sites so we can go take a look at the actual code. I would genuinely like to see it.

  101. 101

    Luke Scammell

    June 20, 2012 3:20 am

    It sure is a good example – it’s a relatively simple, single page!

  102. 102

    Heydon Pickering

    June 20, 2012 12:23 pm

    Who the hell is adding a page-level header to your document without telling you and why the hell wasn’t there one included in the first place?

  103. 103

    Jason Marshal

    June 20, 2012 3:32 am

    A terrible analogy there, but if it was good I think you’d have defeated yourself with your own example. Which is clearer? Actually I’d much prefer to follow the contextual directions as they give more detail, clear defined points to act and even fail safe just in case things go wrong.
    The explicit directions are terrible on the other hand – apart from Heydon’s point of where is market street? there’s the question of turn left where? the first, or second turning? at the end of the street?
    It’s also not how most people do things – they see landmarks, how many people read the name of street signs? If you do you might realise not every street is marked, and when they are it’s usually at the either end – come onto a street in the middle and you have no idea what it is.

    the one analogy that is good is about building cities – and most cities are a terrible mess, bad traffic, one way systems you get lost in. Why? Because a city never starts out being built to be a city. It’s usually a town that grows. A cobbling together as something that never quite balances.
    I think Heydon’s ideas are something you do to make a perfect city. It’s when you start a new project. Most arguments here seem to be about big monstrosities that already exist – yes classes are a life saver in such a case as it’s hard to go back a restructure things correctly.
    I’ve been trying to apply the principles mentioned by Heydon for some time now and thankfully HTML 5 introduces a few more tools to achieve it. Yes I do use some classes, but they are few and far between and just add a final bit of flare, but core site styling doesn’t need it at all.

    A good article, it’s ideas like this that help streamline the principles of programming and remind people that the tricks they have learnt to get past past issues have turned into unnecessary bloat.

  104. 104

    Heydon Pickering

    June 20, 2012 3:41 am

    Agreed. No one really wants to build cities. They are an unfortunate outcome over overpopulation. Sort of like the vast module repositories of badly policed open source CMS’s.

  105. 105

    Heydon Pickering

    June 20, 2012 3:48 am

    Yes, I like simple web pages too.

  106. 106

    Martin Chaov

    June 20, 2012 4:00 am

    Think of this:

    Image we have a certain information in one block. What if I want to change it, not much, but let’s say enable a certain functionality after the user has been logged into the system. The code will stay the same, but the visuals have to be a bit different. How are you going to differ the same markup in CSS?

    The same case can be observed for systems that have multiple levels of access with layouts updated via JS.

    I won’t go into how the performance will drop down if you have a large scale application and rely on your approach for selecting elements for manipulation with JS.

    Your “idea” is not that bad, but it will work best used in combination with CLASSES’ and IDs. This will increase the scalability of the system and will give you more re-usable markup.

  107. 107

    Luke Scammell

    June 20, 2012 4:02 am

    It doesn’t, best practice says “use semantic markup with classes where needed”. But your article says “don’t use classes at all” which is impractical in a lot of cases in the Real World™.

    That’s what all the upset is about really, and if you actually believe “use semantic markup with classes where needed”, then you didn’t make this in any way clear in your article.

  108. 108


    June 20, 2012 4:30 am

    > “Does the WYSIWYG editor in your CMS output markup with classes? I doubt it.”
    From my experience and the way I’ve interpreted OOCSS in my work, OOCSS isn’t there to tackle CMS output; it’s there for the rest of the site…and when you’ve got a big ass site with lots of page elements, THAT’S A LOT.

    > “…that doesn’t make it impossible”
    Just because it’s possible doesn’t make it the more logical, manageable solution. You said yourself that it “requires some more planning and thought upfront”…so why choose it?

    > “I suspect the real problem is that such a website is already crippled by too many classes and inefficient CSS.”
    No, the problem is that such websites are massive…they are never “finished” because they often have ongoing work or have functionality rolled out in phases.

    Fact is, using the “class-less” method is fine when the project is relatively small, subject to little / no change, is made by one person and is done in one swift build. When have you heard a large scale project work like that?

    OOCSS prepares a site to be scalable and/or manageable, because it applies a logical, familiar structure; any developer can jump in, months since the project was last touched and be relatively certain that their work won’t have repercussions elsewhere.

  109. 109

    Luke Scammell

    June 20, 2012 4:30 am

    It sure does, but I have no control over which CMS is used, and I’m sure a lot of others who have posted are in the same boat. I also have no control over the 3rd parties currently being used. Am I trying to do something about it? Yes. But until I succeed, I’m very limited as to the quality of the HTML output apart from within an ID’d container within the layouts.

    I’m not arguing that content necessitates a complex/difficult CMS that outputs poor HTML, I’m arguing that in the Real World™ a lot of us have to deal with just that.

    In an ideal situation, I’d be able to control the quality of the HTML and the layouts etc, then I would actually be able to use fewer classes, but this is simply not the reality of my situation. I know a lot of other people share this reality.

  110. 110

    Heydon Pickering

    June 20, 2012 4:51 am

    I agree that in the ‘real world’, we do often become burdened with inheriting poor, difficult to manage HTML. I wrote this article to help, albeit in a small way, to diminish this trend.

  111. 111


    June 20, 2012 4:53 am

    (this is a reply to Haydon, comments don’t nest this far!)

    The major flaw in the “class-less” approach is that it is completely reliant on the HTML never changing. Fact is, in larger projects, it does…all the time. Stuff gets refactored, added, deleted and changed. Do any of that, and you have to check that the CSS doesn’t fall over.

    I looked at your blog and did spot that you’ve done it “class-less”. This is fine…FOR YOU. If I – or anyone else – had to step in to make changes, I’d have to understand the majority of the DOM and/or site scope just to touch it (as Tom Giannattasio said). Part of the idea of something being scalable is that it is manageable; simply put, your “class-less” approach isn’t so. (read my later comment for more)

    Do you not think taking one site out of context is silly?

  112. 112

    Heydon Pickering

    June 20, 2012 5:20 am

    The CSS does not ‘fall over’ using my approach; it changes correctly to reflect the reconfiguration of the content. This makes good, semantically planned websites easier to manage.

    If you design your site so that the CSS does not change (or ‘fall over’, as you put it) when the markup changes then your CSS schema is – by definition – incapable of describing the semantics of the content.

    Your clients may insist on you doing it wrong, but you are still doing it wrong.

  113. 113

    Heydon Pickering

    June 20, 2012 5:22 am

    My remit was to foster debate.

    We now have more than 100 comments.


    For facts, I refer you to the existence of Saussurian semiotics, the word “cascading” in the acronym CSS and my own website.

  114. 114

    Niels Matthijs

    June 20, 2012 6:00 am

    Indeed your blog falls short as a use case.

    It’s funny but the first bit of actual html code (the span for skip links) is already debatable (tag-semantics), as it contains no inline content (the links are separate from the heading). The span however is used as a css differentiator (the div that follows it needs different styling).

    Also div + div is maintenance hell and should be avoided on any site that hopes to live past its release. Another problem with your blog is that it holds only one content type, which makes it so much easier to implement what you’re suggesting here.

    So no, even after looking at your blog I’m not convinced that this is a good idea. I guess not much changed since people started suggesting this 7 or 8 years ago (when the +, ~ and > combinators found proper browser support for the first time)

  115. 115

    Aaaand, now in practice:

    It doesn’t work in IE7 and IE8 because those browsers don’t recognise unknwon elements. There’s a hack, but it requires javascript and can cause a page to jump back and forth, depending on how fast the script loads/executes.

    Not using classes, but tagnames instead. How do you propose to give an element a dual function? Or a function that implements another? With OOCSS this is no problem at all. With roles, this is possible, but css will have to be written with slow attribute-selectors.

    This is a well-written article, but it won’t work in practice. You can’t seriously expect to use this in a real project.

  116. 116

    Heydon Pickering

    June 20, 2012 6:16 am

    Spans have no semantic meaning, like divs. My usage is not incorrect, they are intended as inert wrappers. I don’t like this configuration at the top of the page, but I took the hit for accessibility and responsivity.

    Div + div is not maintenance hell if used sparingly and appropriately. In my site, body > div + div effectively means ‘sidebar’. I prefer this to using a class or ID reading ‘sidebar’ because, due to the responsive design, it isn’t always on the side. It is equivocally a ‘sidebar’ but unequivocally a div following a div. I have separated style and content.

    My site actually has six content types. I’ll soon be supporting a product list type as well. Don’t be fooled by the simplicity; it’s by design, not technical necessity due to a lack of classes.

  117. 117

    Heydon Pickering

    June 20, 2012 6:25 am

    The slight visual glitches in IE8 are due to experimentation with custom web fonts w/ pseudo-content, not the lack of classes or the fact that the page is HTML5.

    I’m not supporting IE7.

    The negligible impact of slow selectors is more than compensated for elsewhere. My Yslow rating is 95%.

    Give me an example of an element with a duel function.

  118. 118

    Luke Scammell

    June 20, 2012 6:48 am

    Quote: Sorry, it’s a new technique and I have not had the opportunity to use it for many clients.

    Interesting. So, how can you even know if this will work well on a complex site?

    Also, what if you suddenly have to deal with a new “user account settings” bar being added to the top of your site? Suddenly, your div + div is your content and not your sidebar. Whereas your .sidebar is still your .sidebar…

    This happens in real life on real sites – perhaps not every day, but regularly.

    With your method, it only works if communication between teams is good and everything is fully planned, or there’s just the one developer. But even if this is the case, you *still* have to go in and adjust the CSS with your method for this change, whereas using the .sidebar class method nothing extra needs to be done. In fact, you can get by with communication between teams being poor or, as is sadly often the case, non-existent.

  119. 119

    Luke Scammell

    June 20, 2012 6:59 am

    Fair enough, but I don’t think that came across clearly in the article, flame-bait title aside.

  120. 120

    Luke Scammell

    June 20, 2012 7:24 am

    Wish I could afford the luxury of ignoring IE7 let alone IE6. Maybe in another 5-10 years…

    And touché again on the “duel” ;)

  121. 121

    Niels Matthijs

    June 20, 2012 7:42 am


    spans and divs don’t have semantic meaning, but they still say something about the content inside. Spans are for inline content (can be read as a sentence), divs are for block level content (separate content entities). In your case, a div is needed, because “HEYDONWORKS Categories About” makes no sense at all. On top of that, divs have structural meaning, and just looking at your header/(main)/aside/footer setup I feel that most of the structure is lost. For that reason I also suggest that you take your site header outside the main content area, as it is supposed to “head” your entire side, not just the content.

    As for div + div, if you suddenly need another div above those two (for whatever reason) your whole structure falls apart. It becomes worse when you need this top notification only on a strict selection of pages (not on every page). Sure you can work around such problems, but then your methodology affects the flow and outcome of your site. I prefer flexibility.

    Looking forward to how you present these other content types. So far I only see blog posts/articles on your blog, maybe I missed a section?

    I still agree that OOCSS is definitely not the way to go though :)

  122. 122

    Heydon Pickering

    June 20, 2012 7:47 am

    Read the article and my comment again, man.

    If my div + div becomes content, not a sidebar, this eventuality will be manifested by… the content that makes it so.

    By using the class .sidebar, it does not remain a sidebar. It still becomes a (main) content container but with an erroneous class attached to it; a class that presumably makes it keep looking like a sidebar. WHICH IT ISN’T, DUE TO THE CHANGE IN CONTENT.

    Your method poses a maintenance issue, not mine.

  123. 123

    Heydon Pickering

    June 20, 2012 8:06 am

    The markup differentiators are the tags themselves, which come with different names, and their locations. Like I said, if this system is good enough for the English Language… I don’t care about the purity of HTML content so much as using the purity of HTML content to help ensure a clear user experience. They are experiencing a document. I mark it up and style it as such.

  124. 124


    June 20, 2012 9:01 am

    I feel for you, but it doesn’t making Heydon wrong; it makes your employers idiots.

  125. 125

    Luke Scammell

    June 20, 2012 9:37 am

    Here’s an example of what I was saying.

    I’ve made the “footer” yellow using your method and put a black border around it using a class:

    Now uh-oh, someone’s added a header without telling us:

    The class based styling of the footer is still black bordered, but, oh dear, the content background is also yellow now as well. I guess we’d better edit the CSS as well in that case.

    Please explain how doing it your way is better…

  126. 126

    Trevor Norris

    June 20, 2012 10:04 am

    Heydon, great post. Really enjoyed the forward thinking on the future of semantic and reusable CSS and HTML.

    After having worked on eCommerce sites that had so many CSS class selectors it reached the upper limit of what IE6 could handle, it’s refreshing to read how better use of tags can remove that hellish nightmare. If for no other reason, it would require developers to think through how the site is being put together.

    IMHO, having come from that sort of background, I would say that use of classes in a CMS system can quickly become so cumbersome and painful that re-factoring is dang nigh impossible. Let’s take a quick survey of product pages on eCommerce sites: – 120 classes – 97 classes – 185 classes – 260 classes

    So, all those who are saying “it would be impossible to refactor my site if all my selectors were using HTML”, how easy would it be to refactor a site that is using approx. 150 CSS selectors? No, from experience I have come to believe that class selectors are needed by large clients like those listed above because they are incapable of asking for a consistent look and feel across the site. So class selectors are added everywhere to bend the page to their will on-demand.

    If there’s a happy medium, I would say it would be to use an id in the parent most element of a section of content. Then use proper HTML semantics and CSS selecting to style the content, using the id as the head selector. Basically a way to enforce a type of Web Components that Paul Irish mentioned earlier.

  127. 127

    Danny Moerkerke

    June 20, 2012 12:07 pm

    IE 7 & 8 won’t be around forever (thank God for that) and did you argue against using CSS in the past because certain browsers didn’t support it (properly)?
    I think we should not refrain from using (new) technology just because it is not yet properly supported in all browsers when there is an acceptable polyfill.

  128. 128

    Heydon Pickering

    June 20, 2012 12:25 pm

    Indeed. Someone is still at fault; it’s just not you.

  129. 129

    Heydon Pickering

    June 20, 2012 1:25 pm

    Precisely: The restrictions of my method are one of its virtues. It is intended as a roadmap for more disciplined semantics.

    As I have stated elsewhere in the comments, having to maintain a classification system parallel to the ‘classification’ system that is constituted by the markup itself can only add complexity and workload. More importantly, though, the developer authored classification system (enabled by the class attribute) is not only superfluous but inapplicable.

    Folks need to stop overthinking ‘interfaces’ and start concentrating on communicating information. If communication is the focus, it soon becomes apparent that the additional weaponry offered by the class is, at best, not needed.

  130. 130

    Danny Moerkerke

    June 20, 2012 1:25 pm

    Heydon, just to clarify: if body > div + div is your sidebar and on certain pages (not all) a new div is added as the first div in the body (before the main content and sidebar), how would you deal with this?
    Wouldn’t this be difficult since body > div now targets the new element on one page and the main content on another?

  131. 131

    Trevor Norris

    June 20, 2012 1:35 pm

    For anyone interested, here’s the link to the code I used to grab the number of classes on a given webpage:

    And for fun, here are a few more eCommerce product pages: – 149 classes – 222 classes – 173 classes – 573 classes (total length of 10,262 characters)

    If nothing else, developers should consider the impact this technique would have on their website. It might not be completely possible in your case, but for the love of… 573 classes?! That’s at least an extra 15KB (don’t forget the characters in ‘class=”” ‘) you’re adding to your markup in class names alone.

    Take this article into consideration while developing a new site. Ask yourself, “Is it really absolutely positively necessary I add a class to this element to achieve style X?”

  132. 132

    Enrique García

    June 20, 2012 1:54 pm

    I think “sub-optimal” and “not fit for purpose” have sufficiently similar definitions to make the distinction completely irrelevant. You have chosen to concentrate on that distinction and ignored my main question completely.

    I can only conclude that you are not able or willing to supply the evidence I consider valid at this point. Please create & submit another story to Hacker News if you are able to do so in the future. I’ll not be coming back to this page again, so please don’t bother answering here.

    Good luck with your approach.

  133. 133

    Danny Moerkerke

    June 21, 2012 4:27 am

    Stef, we all could probably think of a million situations in which this would be very hard to implement. But that doesn’t mean this approach is flawed. What if you have a very large website with table-based layouts and lots of inline styling? It would also be very hard and costly to introduce DIV’s and decent CSS. Once upon a time, this was how it was done in “the real world”. If semantic HTML and CSS would have been disqualified back then because is was “not for the real world”, we’d still be doing table layouts.
    To disqualify an approach just because it is hard/costly/near impossible to apply to existing situations (which might already used flawed techniques) is narrow-minded. Give it some thought and if you then conclude it is not for you, then fine. But don’t disqualify the approach as a whole just because it is hard to apply to every single situation.
    I have inherited a large legacy application which contains every single programming anti-pattern known to man, multiple times. We have tried to implement a decent MVC-model which was a real hell and very costly, so in the end we had to give up. Do you think it made me believe that the MVC-model was flawed? We rebuilt the application from the ground up using MVC and still reap the benefits everyday.
    Now MVC is a proven technique and it remains to be seen if Heydon’s approach will be just as useful, but I’ll give it a try. It’s articles like these that paved the way for semantic HTML and CSS when the real world was still doing table layouts.
    CSS has native support for inheritance – the cascade – to improve modularity en code reuse. It makes no sense to build another layer on top of that which does the same thing. In experience everyday that using lots of classes is how it is usually done in the real world. But that doesn’t make it right. It merely indicates that most people take the easy route because they have never been taught how to use CSS the way it was really intended.
    Table layouts make certain things much easier to do then with DIV’s and CSS. But very few people call that “right” nowadays.

  134. 134

    Heydon Pickering

    June 21, 2012 6:00 am

    My technique works on sites of any size. Its only restriction based on the modularity of nestable HTML, which is near-infinite.

    Why do you assume that you’d have to know the entire scope of a website to apply changes? Are you a print designer? Few of the elements in the pages on my website would change in appearance when moved and – of the ones that did – I would almost always want them to.

    In addition to this, consider the finite selection of conventional page layouts that any sensible web designer might consider. 2 columns + footer? three columns? header in left column? footer in right column? Once this basic structure is in place it very rarely changes and you’ll note that it is only on this structure that the majority of my ‘complex’ selectors are based.

    Let me make something clear: I am a web designer. I build websites to be responsive and to tolerate dynamic content. The method I describe in this post caters for this better than one that concretes styles by etching them directly onto elements.

    A final note: If you are building a huge, complex and – therefore – largely overdesigned and pointless application, the negligible performance hit of using inefficient selectors is the least of your problems.

  135. 135

    Julian Gaviria

    June 20, 2012 9:48 pm

    With some CSS preprocessing magic, I can see this argument valid up to a certain point. However, classes and IDs are still going to be necessary somewhere down the line.

  136. 136

    Heydon Pickering

    June 20, 2012 11:37 pm

    I’m going to correct you in your absence, then.

    “Sub-optimal” means it is not as good as it could be. “Not fit for purpose” means it is not good enough at all. I’m not going to insult the remaining commenters by clarifying this any further.

    Classes are not fit for purpose because they cannot be meaningfully computed.

    Sullivan’s work with Facebook was to take steps to make an extremely code-bloated website more efficient. She is a brave lady. The reason that Facebook’s UI code was so bloated was because of iterative changes over time.

    Thanks to the class and ID attributes, which can be used at the designer’s whim, the designer is free to incorporate more and more piecemeal heterogeneity into the UI until it is alienatingly fragmented.

    Not only does this result in an overly complex UI, but in underlying markup that (because the class cannot affect its computed meaning) is not able to communicate the same complexity to bots and assistive technologies.

    This makes the website broken.

    Further down in the comments, I’m charged with making a website as complex as Sky Sports using my methodology. I concede: There is little chance of me making a website as hideous as that of Sky Sports ( without throwing classes all over the place.

  137. 137

    Heydon Pickering

    June 20, 2012 11:51 pm

    Just to clarify, body > div + div is not my sidebar. It is an unsemantic container following another unsemantic container.

    Should I style this div using float:right it will become something of a ‘sidebar’.

    What’s more important, though, is that – whether or not it appears to the side – this div contains an aside and a footer. It is this content that defines it as ‘tangental’, not its visual position in the layout. If a new div container precedes it the semantics are unchanged. There’s just more main content before the aside and footer.

    In order not to affect the layout, I would place the div inside the first div in body > div + div (before the original content). By doing this, the second div in body > div + div is still targeted the same.

    The introduction of the new div does not affect the document outline, only the order of content.

  138. 138

    Heydon Pickering

    June 21, 2012 12:06 am

    Check my document outline here:

    It is sound.

    Thanks for the tip about the “HEYDONWORKS Categories About” problem, but it is off topic.

    I replied to Danny Moerkerke about the div + div issue…

  139. 139

    @Heydon Pickering
    “Who the hell is adding a page-level header to your document without telling you and why the hell wasn’t there one included in the first place?”

    I tried to avoid commenting but this made me…

    You just proved what everyone here has been saying, you have no concept of working on large scale projects with both onshore and offshore development teams, political agendas in a large corporate environment.

    I have just moved on from a multi-million pound financial project that had upwards of sixty developers being supported by a team of five front end devs/designers. The developers grasp of HTML was varied from decent to abysmal, the HTML was generated by JAVA, and it was a constant struggle to try and retain some semblance of structure to it.

    The management team had promised the market the project would be delivered on time (a timescale that was almost impossible to hit), global clients with user bases of upwards of forty thousand staff were expecting the web app to launch when the sales teams told them it would, and brand compliance were sitting over our shoulders making sure that it adhered to their spec. Try and pull all this together this century *without* classes?

    This approach is not real world. Sorry. Nice idea though.

  140. 140

    Maybe you just want to fade the second article back for visual effect?
    Just sayin…

  141. 141

    “Not supporting IE7”

    Not working for any FTSE100, or large blue chip company.

  142. 142

    Heydon Pickering

    June 21, 2012 1:47 am

    If I change the appearance of an element, it will change the appearance of all elements of its type.

    This is a good thing.

    If I want to treat elements of the same type differently, I refer to their context. I refer to context because context is pertinent. That is, context is a legitimate differentiator. It is the only legitimate differentiator in the universe aside from the intrinsic qualities of the items being compared (their element types, for our purposes).

    Context, like element type, is computable.

    I am trying to present taxonomically computable information to a human user.

    What is it that you are trying to do?

  143. 143

    Martin Chaov

    June 21, 2012 3:05 am

    First of all I don’t want to change everything. Second I have menus that are using the same code but have to differentieted, and third, I can’t use advanced selectors only because these menus are not always shown (all of them, but a few) and they appear on a different places of the page.

    No way around this … and please for the love of god, please stop explaining how it is good to change everything wich uses the same structure. NO it is not.

    It is not good that I can’t re-arrange my GUI because the elements are styled with selectors only and are dependend on the number of children around them.

    So … for your blog :) I am glad it works, for a CMS backend … it doesn’t.

  144. 144

    Heydon Pickering

    June 21, 2012 3:11 am

    An ironic observation, given that the thrust of my argument was that classes are detached from ‘real world funtions’. Which they are. Unless they’re microformats.

  145. 145

    Heydon Pickering

    June 21, 2012 3:15 am

    Since the object of the article was to explicate that authored classes are always detrimental to optimal HTML+CSS design patterns, saying they were okay sometimes would actually reduce credibility.

    I am serious about this and you will have to be too.

  146. 146

    Heydon Pickering

    June 21, 2012 3:20 am

    I just checked again. Out-of-the-box Drupal still outputs atrocious, class-ridden markup.

    I have a life and I don’t want to spend it cleaning the output of over-engineered CMS’s – even where it’s possible to clean them. I want to spend it communicating information.

  147. 147

    Heydon Pickering

    June 21, 2012 3:21 am

    The same goes to you: I’m not interested in fixing bad CMS’s; I’m interested in making websites.

  148. 148

    Heydon Pickering

    June 21, 2012 3:40 am

    I’ve explained this elsewhere but I’m going to do it once again:

    My methodology is eminently scalable. I know this because HTML is eminently modular. QED.

    Scalability requires planning and good planning anticipates change.

    Classes do not make scalability easier, they make it more difficult. They introduce complexity.

    We resort to classes when our application does not scale properly because they let us cheat and tweak appearances without obligation to the underlying semantics.

    If you have to cheat, cheat. You’re are still doing it wrong, though.

    The purpose of this article is not to identify how websites are made ‘in the real world’, it is to suggest how websites should be made ‘in the real world’.

  149. 149

    Heydon Pickering

    June 21, 2012 4:40 am

    Thank you, Danny.

    CSS was intended to style HTML documents and, if these documents are written semantically, the class is made obsolete.

    When designing application interfaces, the complexity of the UI may require additional styling hooks to help realise that complexity
    of interaction.

    In this circumstance, I urge readers to consider the role attribute and the many standardised, accessible and computable name-spaced
    values the schema has to offer – many of which are designed exclusively for application (rather than document) style interfaces.

  150. 150

    Danny, have a look at this:

    Real world is not table based (however for some it is). Real world constantly evolves with the shifting sands of ‘updated’ requirements, of role dependant interfaces and multiple user journeys, of finite budgets and performance. As many above have stated, this isn’t real world, and nothing that has been said in the article or following comments makes me think that this would work in anything like an enterprise level endeavour.

  151. 151

    Heydon Pickering

    June 21, 2012 5:17 am

    I agree. Trying to get bad developers to write good HTML+CSS is not easily feasible. The fact that you work with an oversized team of incompetent developers does not make it the case that my methodology has no efficacy. You have commited a logical fallacy.

    Nonetheless, surely one of the 60 developers in question would notice a missing <header> element in the original prototype. If it was missing – due to some sort of collosal incompetence regarding basic HTML document structure – why would he then include one BUT KEEP IT SECRET??

    You guys are the fantasists, not me.

    HTML generated by JAVA? I can’t help with that.

  152. 152

    Heydon, does the strength of your argument fall back to simply saying I am wrong?

    I have pointed out a real world scenario in a multi million pound project, within that project I have worked with some of the most talented developers I have had the pleasure of working with. Their skill in JAVA and Wicket far outstripped their skills in HTML and CSS however they were not incompetent, like all things there are the good with the bad but I at no point implied incompetence. By resorting to this level I suppose you show your lack of big corporate experience.

    If you have never worked on such a large scale, regulated project I can imagine thinking that the team would be oversized, if you have never worked on an enterprise level site/application I can see why you would think that having markup generated by the likes of JAVA or .NET is strange however it is the way of the world. It doesn’t mean the markup is bad, it depends on who’s writing it and who’s reviewing it.

    In large projects it sometimes happens (read ‘often likely’) that decisions are made that seriously affect what you do which you may well not have knowledge of. A developer getting a work ticket to add a and then closing that work ticket and moving onto the next critical bug/ piece of work – without informing you at the time is, unfortunately, commonplace in large projects.

  153. 153

    Let’s say you do want to fade the second article back for visual effect — and IMO there are valid reasons you might want to! — `:nth-child(2)` is a perfect way of doing so because it ensures that it’s always the second article that’s selected.

    Isn’t that what you’d want? That it’s the content within a context that defines the styling, not an arbitrary class?

  154. 154

    This reply led me to understand the two sides in a succinct way:

    – If content defines appearance, use classes.

    – If location in the design/document defines appearance, use relative selectors.

    That’s pretty much it, right? We’re allowed to use both? I feel like I may have accurately summed up your 16-page article with two bullets.

  155. 155

    Heydon Pickering

    June 21, 2012 6:53 am

    What is the benefit of that to the user?

  156. 156

    Heydon Pickering

    June 21, 2012 7:18 am

    Nope. To simply say you were wrong, I’d simply say “you are wrong”.

    I only concluded that the project was badly organised and involved incompetent developers because you told me so:

    The developers grasp of HTML was varied from decent to abysmal, the HTML was generated by JAVA, and it was a constant struggle to try and retain some semblance of structure to it.

    Once again, the ‘real world’ is what we make it. We fix bad development by making it good. You are just accepting complacency.

    I HAVE worked in projects that use the multiple-developer-bug-ticket-iterative-change methodology and I believe a classless approach to the front end build would make that aspect of the development better / easier. I’m afraid you’ll have to read my many other comments for the reasons I have.

    I’m not saying bugs are not sometimes fixed in isolation, I’m saying that if an HTML document has been designed once without any kind of header / title then the developer responsible should be fired.

  157. 157

    lol, it’s not about headers, it’s about the craziness of using adjacent selectors (like, as a very simple example, the body > div + div) without resorting to classes.

    I am not, and never have been complacent in what I do, which is UX design by the way, and I have always championed semantic mark-up and standards everywhere I have worked at. Aiming personal jibes, is less than professional and does nothing for your case.

    SIMPLY USING CAPS does not change the fact that you have not – at a cursory google – worked upon the level of projects I am talking about. I have worked upon internal applications for the likes of Prudential, IBM and Citibank, this involved ground up rebuilds, no table layouts, and had user bases in the tens, if not hundreds of thousands combined.

    Here is a quick question regarding this methodology, how would you target each individual <th> in multiple <tbody>’s when the number of <tbody> elements is dynamically generated by user permissions and data?
    <th colspan="5">data 1</th>
    <th colspan="5">data 4</th>

  158. 158

    Esteban Lussich

    June 21, 2012 7:23 pm

    Your concept is, at least, thrilling. And I am inclined to give you the right on all this. I’ve found myself building pages without a single class, successfully.

    CSS needs classes as much as humans need paintings, songs or sport contests. We can get away without them and go on with our lives like so.

    However we, humans, also need alternative expressive means, to add feel, character, intonation and emphasis to some of the things we want to say. Your article is based on establish relations between the way we use our language, and the way we write our markup, and maybe there is more to the language than words, as there is more to our markup than tags.

    As imperfect as we are, we still need something that could differentiate our message from others, and that could efficiently communicate and express our ideas to someone else, not merely “inform” them.

    And there is nothing better than a good ol’ class to get your point across.

    I hope you understand my point.
    Thanks for your time.

  159. 159

    Jeff Greenberg

    June 21, 2012 7:33 pm


  160. 160

    Laurence Cope

    June 22, 2012 12:30 am

    As long as the HTML and CSS is built well and efficiently, taking into account maintenance and scaleability, following a structure and naming conventions that all your team understand, then there is absolutely no reason to stop using classes. Our first class on our pages is “nojs” which we change to “js” using JS so we can target nojs/js elements. I would envisage a no-class approach being over complicated for no reason.

    If someone said using a class will mean a massive drop in performance then fair enough, but if not then there is no reason to not use them.

    I sometimes think these sort of blogs are written to “try to be different”, “create unnecessary discussion”, perhaps just to drive traffic, and not have a valid argument. It all comes down to science for me…. If you show us some graphs of speed comparisons when using classes v selectors and other “user affected” arguments rather than talk about semantics and paradigms etc. then I would take more note. I dont think my website end users care about semantics in the HTML, they care about speed, user experience, getting information quickly, making sure it all works, etc. I dont build sites for MY benefit but for my users. If it means a few classes that have no negative impact on the web users then so be it!

  161. 161

    Well, this is interesting, but i cannot agree with this approach. While it may be good on small projects, it’s completely useless on big ones.

    First of all – i can imagine working with JS on elementes without classes and ids. I mean – it is possible, but wouldn’t be annoying to get nested elements from DOM. It wouldn’t be much of an efficient method, won’t you agree?

    Second of all – i read your comments and i still can’t find any practical example of using your method on large scale project. I would gladly see your method implemented on ie. Facebook or Amazon front page.

    Last but not least – does anyone even care, that this kind of approach is higly unefficient? I guess you’ve heard that using “.my-link:hover” is much faster than “aside nav ul li a:hover”.

    1 browser request for render vs. 5 browser request for render – which one would you choose?

  162. 162

    Heydon Pickering

    June 22, 2012 2:32 am

    Thanks for your considered comment, Laurence.

    The structure and naming conventions understood by everyone are prescribed in the spec’ as elements and document structure guidelines. These are all you need. As I’ve noted elsewhere, the extraneous structure and naming conventions posed by classes just adds needless complexity. Semantic HTML is your friend.

    The WWW is primarily for organising and communicating information. This has to be made a priority. Semantics are more important than script performance and script performance is only relevant in complex applications. The majority of the (worthwhile) internet is not made up of these high-interaction programs.

    Wikipedia does not rely on masses of scripts and interactive enhancements to increase interest, it simply offers masses of good information.

    If you are writing a complex application there are plenty of additional styling hooks offered by ARIA roles. These roles make your application more accessible and interoperable. Use these instead.

  163. 163

    “The WWW is primarily for organising and communicating information”

    How doeas using classes interferes it?

    “Wikipedia does not rely on masses of scripts and interactive enhancements to increase interest”

    Your right. And it also uses classes, how about that? And that’s another thing – social proof. Everyone uses classes and I mean everyone. So far you recalled one example of page, where paradigmatic styling (i like the name :) is beeing used – your own blog. and to be honest it isn;t much of a complicated piece of coding. I want you to give me more comlicated example, the one with mulitoclums grid layout, lightbox for images, expanded formsm navigation an IA. When you show me that it is possible to build complex page using paradigmatic styling, then you’ve got my sword. :)

  164. 164

    The WWW is primarily for organising and communicating information. This has to be made a priority. Semantics are more important than script performance and script performance is only relevant in complex applications. The majority of the (worthwhile) internet is not made up of these high-interaction programs.

    I don’t disagree with the above, apart from e-commerce and social media sites most content on the web is ‘dumb’ however I do disagree that the user experience of the web has to resemble a wiki, and I think the majority of users and consumers of content would agree with me.

    Take a look at the BBC site, the bbc news homepage in particular ( I think you would agree that it is a content rich site, in fact one of the premier news outlets for the world.

    They are passionate about content and semantics, It most definitely uses ARIA, (I have experience of working with the BBC, they take accessibility very seriously) but, the code is littered with classes. Why? to provide both maintainability and an excellent user experience. ARIA is great for what it was designed for, providing Accessible Rich Internet Applications not shoehorning into providing hooks for styling content.

  165. 165

    Heydon Pickering

    June 22, 2012 3:29 am

    You make a compelling case and one that is much more pertinent than the standard technical gripe that my methodology won’t allow for scaling. However, my following response does relate to this idea of scale.

    I pointed out in the article that the vast majority of texts (poems, essays, novels etc.) were written using the same lexicons of agreed words with their associated meanings. I then likened this to our use of agreed HTML tags and their meanings. The idea, borrowed from Saussure, was that the modularity of language was the enabling factor in the forging of any new, individualised, complex or tacit meaning and that the possibilities were near-endless. Since HTML is also modular (both paradigmatically and syntagmatically), I likened the two.

    I accept that this analogy may have failed in expressing my point. I’m now going to use Lego™

    There are few restrictions to what one can ‘say’ with HTML just as there are few restrictions to what one can make with a set of different Lego™ blocks. The types of block are finite but you can always get more of any type and make radically different configurations by sticking these different pieces together in different ways in their different relative quantities. Lego is scalable.

    Now… I have never felt the desire, when using Lego, to brandish a hand saw and cut the pieces into shapes of my own making. Why? Because I know that, if I stick to the rules, there are still ways to achieve what I want without taking out my saw. If I had resorted to the saw, I would have created a lego piece that perhaps solves my immediate problem more quickly. However, I have taken a familiar, versatile Lego block and tailored it for a specific purpose of my own imagination. The next time I, or anyone else, opens the box of Lego bricks, there is one brick that’s much less popular than all the others.

    For feel and character, expand your vocabulary.

    For emphasis, there is the <em> tag.

    For intonation and expression, get offline and talk to real people, face-to-face.

  166. 166

    Heydon Pickering

    June 22, 2012 3:45 am

    To target “each” th, I would simply use the CSS selector th. The tbody ancestor is irrelevant since it is common to all your th tags, as it should be in valid table markup.

    Internal applications are not websites. If they are internal, I don’t (thankfully) have to see or use them. That is your own misfortune.

    Once again, I am not attacking you personally; my accusations of incompetence were levelled at a team you described as poorly equipped in skills relating to HTML within a system that you descibed as structure agnostic.

    Good luck and I apologise for not working for IBM.

  167. 167

    Sorry to reply here but it seems we’ve reached the limit of replies!

    To target “each” th, I would simply use the CSS selector th. The tbody ancestor is irrelevant since it is common to all your th tags, as it should be in valid table markup.

    Internal applications are not websites. If they are internal, I don’t (thankfully) have to see or use them.

    That doesn’t solve the problem of making each TH a different colour (and consistently, irrespective of where it comes in the table) – as an example. we have a table with lists of music, books, TV shows, and movies. A user may see only TV shows and movies or any combination. If TV shows has a blue header how can you consistently target it if it can appear in any order? A class of tvShows is both descriptive and useful, and it would allow the element to be consistently presented.

    I would disagree that a web based application, delivered through a browser using http/https is not a website, many of them have portals out there on the WWW not just hosted behind firewalls. All of the applications I worked on could be logged into from anywhere, via the web.

  168. 168

    Heydon Pickering

    June 22, 2012 3:58 am


  169. 169

    Heydon Pickering

    June 22, 2012 4:04 am

    Paradigmatic styling is being used absolutely everywhere, all the time.

    The paradigm I am describing is your choice of HTML tags.

    You can’t write HTML without HTML tags.

    Not even classes can make that happen.

    Your sword?

  170. 170

    Heydon Pickering

    June 22, 2012 4:10 am

    Not logged into by me.

    I misunderstood your original question. Don’t use classes to differentiate them, use computable attribution such as microdata. You’ll find most of the relevant types and sub-types here:

    Welcome to the Semantic Web. I’m new here too. Exciting, isn’t it?

  171. 171

    Heydon Pickering

    June 22, 2012 4:15 am

    I don’t recommend using ARIA roles just as arbitrary styling hooks. I’m saying that ARIA roles offer a legitimate way of differentiating content that is not possible just by element type and context. If they represent a real difference in nature, then there’s no harm in reflecting this difference in the visual style.

  172. 172

    Sorry but your answer doesn’t actually address what I was saying (and also it ignores the fact that visual changes may not relate to simply differentiating content but just to good user experience). I do not think your methodology would scale up to a site like the BBC news portal, I just don’t think it could cope with it and still deliver the performance demanded from such a high profile site.

    Not logged into by me.

    I misunderstood your original question. Don’t use classes to differentiate them, use computable attribution such as microdata. You’ll find most of the relevant types and sub-types here:

    The fact that you have not logged into any of these applications does not invalidate my point. They are websites, even if they are not publicly accessible by all and sundry. They use the same technologies, are consumed via the tame tools, and have the same issues with browser compatibility that your blog has.

    Microdata is all well and good but again I feel you are attempting to shoehorn microdata into something to allow us to change the presentational appearance of the content.

    Lets remember that CSS is there to make content look good. To enhance the visual appearance of content, be it a news article, tabular data, holiday pictures, whatever. ARIA is for accessibility, Microformats are great for discrete blocks of content, like a movie listing, or a hCard, and are useful for robots, but neither works well or efficiently when it comes to styling.

  173. 173

    Danny Moerkerke

    June 22, 2012 5:16 am

    Using classes and ID’s as Javascript hooks is entirely different from using them for styling. And Steve Souders already pointed out that even for huge sites CSS performance is not an issue:

  174. 174

    > Paradigmatic styling is being used absolutely everywhere, all the time.

    Yeah, but not in the way you describe it.

    > Your sword?

    You havent’ seen Lord of the Rings, have you? :)

  175. 175

    Heydon Pickering

    June 22, 2012 6:30 am

    If you have sub menus, nest them. If they are nested, simple descendant or direct child selectors will suffice.

    If you have multiple menus that are not nested, then they are of equal utility and importance and should look the same. However, for aesthetic reasons and for better separation via, say, background color, then the adjacent sibling combinator is fine. Why? Because the style is needed only when they are adjacent. If they are later separated, the color differentiator becomes redundant and, using this methodology, is automatically no longer applied.

    CMS’s are for managing content. As long as the output of the CMS is semantic, I don’t care. If it is sufficiently semantic it won’t need classes. If it is application-like, use ARIA roles to describe the enhanced functionality properly.

  176. 176

    Heydon Pickering

    June 22, 2012 7:24 am

    You are one of the very few commenters who seem to get what I’m saying, Dominic. Phew!

    I agree: The :nth-child(2) solution is better because it styles whichever item is in the second position. This saves on writing control structure logic at the back end, which would be more verbose and more difficult to maintain.

    I’m still wondering what the use case is though :-)

  177. 177

    Robert Wünsch

    June 22, 2012 8:25 am

    So, is my observation correct that you are saying “Don’t use CSS classes like .main-title. Rather try to avoid them or at least give them meaningful names like .recommendation or better use roles for that” ?

  178. 178

    Heydon Pickering

    June 22, 2012 8:54 am

    The class .recommendation is better than .main-title because there is already an exactly equivalent element for .main-title in the shape of <h1>.

    Nonetheless, neither class is helpful in providing computable meaning to accompany the style. Microdata schema for creative works such as movies allows for the inclusion of aggregate ratings and user submited comments. Some technologies can compute these, including Google’s algorithms. As the Semantic Web gains more support, more parsers will follow.

    I already have clients who ask me about microdata. They are particularly interested on its impact on SEO.

  179. 179

    Older news articles?

    Or, slightly different, but one that I have had to deal with this week, you have multiple authors providing posts in a news feed and each, for branding reasons, has different visual treatments. Tom, bob, and Jane all post articles, the markup for each article is identical – a header, date, abstract and a link to the full article. The headers will have different coloured bottom borders and different author portraits (as background images to the posts which will appear to float left of the header). When an article is older than a week it is knocked back, the background ‘tint’ is based not upon its place, but also on its poster.

    You cannot solve this problem succinctly and robustly without classes.

  180. 180

    I think the day, if it comes, when he has to work on a proper site he will realise how wrong he was.

    If he wants to prove us wrong, he can rebuild the BBC news site using this methodology and have it be as fast. He can’t and won’t because it will never scale.

  181. 181

    Heydon Pickering

    June 22, 2012 3:49 pm

    Each article is differentiated by the different portraits and different author names. There’s no need for aesthetic differentiation. You are looking at the same type of things but by different people. You know the instances of these things are by different people because the names and likenesses of these different people form part of those things.

    Look to the content. Nothing else matters.

  182. 182

    Deborah Foley

    June 23, 2012 6:05 am

    While I your practice appeals to the idea of semantics and also keeping content, style, and behavior separate. I can not see the possibility in recommending your ideas, definately not on larger scale projects. I have tried the principles of osscss smaccsss and drycss. With every style I want to add i think is this unique, repeatable, and how efficient is this code going to be to add. Consideration of effecientcy is how many characters, how will it do in optmization and performance. I like the smaccss idea of modular components, writing one unique semantic class for the wrapper then trying to use that with selectors to use less markup when it’s unique styling. However I could not use the majority of your modern selectors because ie doesn’t play nice with that. As others already mentioned for browser performance alot of your use of selectors do very poorly in optimization. Osscss I have found valuable for I am able to use class conditional recommended by Paul Irish for browser specific code with less code gloating using cascading to overwrite styles. This is also true with the practice I use of writing modular components that can be overwritten for subtle changes and this same practice is valuable for responsive web. Using media queries I can overwrite that one line of style code and not repeat the several selectors that you propose. Your idea is similar to the class I recently took on drycss. And while it reduces code and markup when you try adapting this same code to work in different pages, different browsers, different resolutions and browsers it will eventually get tangled up. Great philosophy, not practical in many situations.

  183. 183

    Having read the article and in principle agreeing with the sentiment I also can’t see this working on large scale dynamic corporate websites and applications. Why? Purely as you have no control over distributed content editors for a start – who knows what they’re going to bang into a useless wysiwyg. “oh, but you should have trained web editors!” Eh? Wake up to the real world where you have anybody and everybody that has no association with web technologies entering invalid ‘semantic’ markup through wysiwyg since it’s not ‘actually’ their job.

    Good thought process – just not actually tenable.

  184. 184

    Heydon Pickering

    June 24, 2012 2:08 am

    I am completely opposed to WYSIWYG editors used as the only editing field for a content type.

    Used as a textarea enhancement amongst accompanying fields in a structured content form, maybe.

    Structured helps make content editing largely foolproof. It’s one of the reasons I like using Perch. The system makes creating structured content a joy.

  185. 185

    Fascinating article! I was totally convinced OOCSS was the answer before I read this article, and now I can feel my brain being pulled in two opposing directions (which oddly feels great.) Before OOCSS, what I was doing was using IDs and classes sparingly, and descendant selectors to get to specific elements (like #header h1, .tweets li a) in CSS and jQuery. The difference between my old style and what you are talking about is your willingness to embrace new HTML5 elements, CSS3 selectors, and mico-format roles so that you can target page elements using no classes or IDs at all.

    I have three qualms with your method:
    – It heavily relies on new technologies. But, that argument is losing ground as the old browsers are becoming increasingly irrelevant, and polyfills improve.
    – There are performance issues with contextual CSS selectors. But, those are milliseconds that are becoming less relevant as browsers and computers and phones are getting faster.
    – The big issue is the complexity and potential maintenance nightmare of contextual CSS selectors tightly coupled to HTML structure. A lot of people who do HTML and CSS aren’t really programmers, and would be very confused inheriting markup with no classes and style sheets filed with + ~ > [ and ] symbols. It could easily confuse me seeing it weeks after I write it. However, my intuition tells me that there are techniques for using your method that keeps code simple and modular – it’s just going to take me and other developers time to discover them.

    I can’t argue with how well OOCSS is working for me right now, and how solid the logic behind it is. But I feel like in the long run, you are right, the no classes method is where the proverbial puck is headed. I think I’m going to stick to OOCSS for now, but keep your method in mind and transition gradually to it, as I discover simple and logical and easy to maintain ways to do so.

  186. 186

    Vladimir Solovey

    June 27, 2012 6:33 am

    The article prompted me to use a bit of my gray matter and re-think the way I use my classes. I do feel that the author is right about CSS classes being overused, while I am not entirely convinced we can get rid of them altogether – at least, for now. However, his article was well written, it offered a different way of looking at CSS and I intend to experiment with Heydon’s ideas and use more selectors and less classes in my next project (small steps). Discussing the pros and cons, in my opinion, are rather pointless without a couple (of hundred) of field tests to back up either point of view.

  187. 187

    Hmm, deleting comments, especially when they add to the discussion is a little suspect.

    Rather than reiterate the entire post, here’s the link to the Mozilla developers network and their take on writing efficient CSS:

    Heydon, please feel free to comment, rather than delete.

  188. 188

    Heydon Pickering

    June 29, 2012 7:28 am

    As luck would have it, I have just been accepted as part of the BBC’s development team.

    My only credential was your recommendation.

    They are confident in my methodology but ask me to instate the new front-end architecture on a slow news day. Just in case.

  189. 189

    Heydon Pickering

    June 29, 2012 7:15 am

    This excellent article agrees with many that selector efficiency offers negligible gain compared to javascript efficiency, number of http requests and image compression etc:

    Your ease of transition sounds sensible. Good luck!

  190. 190

    Heydon Pickering

    June 29, 2012 7:22 am

    It was not my intention to delete your comment, Stef. I was enjoying our debate!

    I was a bit rushed and must have mistaken it for one of the spam ones.

    I have reinstated it and I’m about to reply…

  191. 191

    Heydon Pickering

    June 29, 2012 7:23 am

    Good luck, Vladimir. I do believe my method requires more planning but that this planning should be undertaken in either case.

  192. 192

    Stephen Dixon

    July 5, 2012 8:24 am

    After reading the entire post and every comment including the authors responses, I’ve got to conclude that this just doesn’t work in the industry.

    You can defend your opinion as much as you want and have every right to do so but ultimately, it won’t change what is fact. And the fact here is that using IDs and classes are inherently a non-issue. It just isn’t a problem. Therefore you’re trying to solve a problem that doesn’t exist or more rather, what you’re seeing as a problem factually isn’t for the industry. It’s that simple.

  193. 193

    I appreciate your well written arguments, responses and the fact you clearly knew this post would spark a heated debate, that being said there is one glaringly obvious issue that I haven’t seen mentioned above (granted I didn’t read every comment, so apologies if it has).

    You present your personal blog as testimony to your approach but much of the template design simply fails in Internet Explorer 7/8/9. I realise your background is set with box-shadow, solely a CSS3 property so I’m not expecting that to work, but your article separators, icons and spacing are completely off, it even occasionally crashes IE8. Furthermore this is on a very small site, can you imagine the extra work required to make a large scale site work in this way, does that not even completely negate this method?

    Even if backwards compatibility wasn’t a concern for you it should work in IE9 which is currently the latest version. Additionally if backwards compatibility really isn’t a concern for you and your last post on the 29th June was true, perhaps you should re-think your approach before your first day at the BBC.

    Don’t get me wrong I initially try to take a vaguely similar approach and then supplement my markup with classes where necessary but I believe at this point cross browser/backwards compatibility is far more important than eradicating the use of classes entirely.

  194. 194

    Hi, please consider this: I have to lists in the exact same place, one next to the other, on represent top 10, and the other represent worst 10, they have the exact same tags, as they have basically the same content, yet I still want the worst list to emphasize this is bad, and the best, list to emphasize good. As far as I can tell what you’re saying doesn’t apply here… Though I generally agree there are some things that are just wrong with OOCSS.
    I hope everything I wrote is clear, without too many mistakes, or any difficult to understand parts.

  195. 195

    I’m sorry, well written but I don’ think I’ve ever read such nonsense. I just can’t see how this would ever be possible with a complex design.

    Sure content is king, but content can’t force design through semantics. Sure selectors are super smashing great, but what about backward compatibility. If you want to support IE7 you’re still going to have add a shed load of classes. And surely, it is quicker to and less code heavy to use classes where required.

    Going out on a limb here, but i challenge you to find a stunning website ( which doesn’t use classes.

    cracking lorem ipsum generator… muchos gracias

  196. 196

    Sarah Adams

    July 9, 2012 9:41 am

    “Each article is differentiated by the different portraits and different author names. There’s no need for aesthetic differentiation. You are looking at the same type of things but by different people. You know the instances of these things are by different people because the names and likenesses of these different people form part of those things.

    “Look to the content. Nothing else matters.”

    This is why the no-classes-ever approach will never work. Aesthetic differentiation can help users understand content at a glance, without being forced to read and understand each piece of content first. Other examples where classes are used in this way are: a list of product reviews that uses classes to differentiate the good and bad reviews; a browser support chart that uses classes to differentiate supported, partially supported, and unsupported features.

  197. 197

    Lee Kowalkowski

    July 18, 2012 6:55 am

    Sounds to me like the objections to this post and comments defending class-itis are as if people enjoy having chaotic markup and therefore CSS. I detect an element of pride in having complexity like that is some sort of accomplishment or necessity. Such comments are actually highlighting historical neglect, take some responsibility for allowing the disorder and inconsistency in the first place. (If you’re trying to support multiple templates with the same CSS, you’ve gotta be nuts, isn’t that like trying to combine all the submissions to CSS Zen Garden together?).

    I think the only thing prohibiting me from applying this to a very large scale public website that I am employed to maintain is that we are still required to support IE6-8 (even if IE8 is your baseline, you have to support IE7 because some users seem to be unable to get IE8 out of compatibility view – particularly in intranet mode – unless you’d like to ignore that fact and take the hit with helpdesk calls, spending all day educating your end users how to do it instead of just supporting IE7 in the first place).

    It’s been around for over a decade, and of course, it’s riddled with classes, but I can see how every class we use could be redundant if we made good use of HTML5 and CSS3. – Although, I’m not 100% convinced that would absolutely always be better. You’ve made the class attribute sound like the Swiss Army knife, which despite never being the best tool for any job, is a very handy tool to own never the less.

    Our ~100 web application developers have to adhere to our strict markup regardless, otherwise our existing class-ridden CSS would not work as expected, that’s why we have a developer reference manual for it*, and our application framework and CMS is built against our own markup standards* so our developers produce compliant markup without even realising it*.

    Our handful of designers have to adhere to it too*. If there’s a corporate style for breadcrumbs, forms, menus, whatever, they must use it*, because that is the available solution for that problem. If they can justify why the solution doesn’t solve their problem, then the existing solution changes to support the need, and that changes everywhere*. Then every instance of the component in the live system benefits from the improvement, not just the recent ones. No new techniques for solving an existing problem are created.

    *: If people think they’re working on a complex website, yet they’re not doing this, then it is they that need to get some real world experience. So I’m pretty confident any system of writing CSS can scale given forethought and planning – just like any CSS that is reused for every page on an enterprise would need to, regardless of how it was constructed.

    …so I think it’s entirely possible, but I’m just in need of a tiny bit more persuasion and convincing that classes are definitely a problem (considering I’m not embarrassed by any of my class names, and I considered the class names in your examples poor to start with). But what I’m definitely going to do is walk a mile in your shoes and give it a go the next time I’m doing something greenfield, see how it goes, I might even enjoy it. Thanks!

  198. 198

    Thankfully Mr. Harry Roberts is both a genius and substantially more articulate than myself.

    Will look forward to seeing the bbc’s website covered in ridiculous selectors, I hereby pledge to you twenty of my most precious English notes if you pull it off.

  199. 199

    Vlad Nicula

    July 24, 2012 4:04 pm

    After giving it some though and trying to imagine how I would build a jquery widget and plug it in a web application, I’ve come to the conclusion that this is possible on small pieces of code.

    I recently implemented a widget that scrolls content horizontally using the css column layout. The abstract version of it, which only uses empty divs for the content could be styled without classes, and it works fine. I do have an #id for the div that contains the widget (otherwise how could I tell jQuery which tag I want for my particular widget).

    But since my application on a single page, and I have more types of content that goes into my widget, I need to have some sort of differentiation between books, movies and… smartphones in my item list. Each have similar structure, but different colors.

    How could I implement this without classes?

  200. 200

    This article is the biggest load of nonsense. The authors replies to comments are flawed too. Come on Smashing Magazine.

  201. 201

    Hi Heydon,

    You should stop writing articles like this on Smashing Magazine and start considering to be respectful in your comment replies.

    Top tips: search “css frameworks” and “template engine” to learn something that is related to real world…

  202. 202

    I wouldn’t go as far as to say you’ve sold me — but this article has given me plenty of (dare I say) food for thought. I think the only way I am going to appreciate the idea behind losing classes is to give it a shot. So, for a little while I am going to try to stick with tags instead of classes, and see how I go. If I can do everything that I normally would have been able to do, I don’t see the harm in it. At this time, I am treating this concept as a novelty.

  203. 203

    Ok, I am back already. I use XHTML, and there’s not enough tags to go around. HTML5 has a lot of tags, but it’s not very well supported yet. Then there’s HTML4 (just forget about not using classes with that). The idea of losing classes is ok, but it’s not practical. At best, I think it’s ok to drop the use of classes for every tag that is supported by html4, html5 and xhtml — and that’s just the main stuff really. p’s, div’s and h1’s. That’s my two cents. My problems started as soon as I couldn’t find a substitute for a div wrapper! It went down hill from there. This article sounds good, but in real life.. yeah..

  204. 204

    This methodology can be used for websites built for the “borg”. No taste, no style, just blocks and headings. To drop classes and use tags, well that’s just a glorified XML document, really. If you ant to add left menu’s and right menu’s and floating containers and dropdowns and various containers (ie: there could be 15 different containers) which show up on the same part of the template depending on the page/corresponding content, etc.. then you need classes and you need LOTS of them. I don’t care if you call them Martin, Shane or Matha. There’s no way to build a functional website with a lot of design elements, without using classes. End of story, Period.

  205. 205

    this article is about what kind of roads the A.I. of browsers have to take and how the communications between machine and human should go , not about building web sites from the perspective of efficient & cooperative ways of doing works.

  206. 206

    Thomas Deutsch

    September 6, 2012 6:43 am

    what? …. :D
    Can you inform us on your BBC progress?

  207. 207

    I like this way. I think in future, all will follow html tags rather then classes.

  208. 208

    منتدى أسود الفوركس

    October 14, 2012 10:39 am

    It’s perfect time to make some plans for the long run and it’s time to be happy. I’ve learn this post and if I could I want to suggest you few attention-grabbing things or advice. Maybe you can write next articles relating to this article. I desire to read more things about it!

  209. 209

    October 16, 2012 5:54 am

    You want to control your content and control your website design then I suggest MODx.

  210. 210

    David Siegfried

    October 17, 2012 1:29 pm

    On the whole I agree with your point. Using classes is never optimal, however it is sometimes unavoidable especially for those of us who either work with designers who do not see design in the same way and clients who want their way. I believe there are times when they can be of use, semantic to a point and necessary.

    Personally I feel your biggest issue here is that you come off as an incredible asshole in your comments and as an arrogant prick in your article. The notion to stop using classes is a scary one to many designers/developers and you are not doing any favors to your cause by cramming it down their throats about how their way is wrong and they are less intelligent for not knowing your way.

    It is always better to ease people into things if you want to make some headway, we don’t need an article on how to get rid of classes altogether, but, how about instead of this write-up you pen a helpful article outlining some ways to avoid them in your day to day work?

  211. 211

    I will go ahead and assume that because I find this article ridiculous. No one with a lot of large project experience can take you seriously for this very reason. Any by large project I do not mean clicking install for “drupal” and creating a mom & pop website, I mean comprehensive sites that a team of people work on full time.

    So are my assumptions right or are you going to show us an example of this experience.

  212. 212

    This is off topic but my inner pedant won’t let me leave it alone. Plenty of people do want to build cities and cities are not generally a product of overpopulation.

    Cities developed because commerce, learning, innovation, cultural exchange, and many other functions important to civilization are made more efficient when lots of people congregate in close proximity to each other.

    All that said, I don’t know what, if anything, this means for your and Jason’s metaphor.

  213. 213

    The best approach is limiting how many classes you create by maximizing the use of HTML5 markup such as header, article etc. Not using ANY classes is the most ridiculous idea, especially if you are creating a large site that requires many divs. Not to mention divs that require relative, absolute positioning.

  214. 214

    Stumbled across this whilst picking through new ideas …

    Fascinating article and concept with a very robust discussion after – it certainly ruffled a few feathers.

    It’s a concept I’ve been skirting around the edges of for ages – I despise overly complicated CSS mark-up and find wading through reams and reams of classes – even well constructed OOCSS can be *very* time consuming.

    I’ve always practised using as few styles as possible, using the raw html mark-up to do as much grunt-work as possible. Generally, that amounts to using a lot of container classes and inheritance.

    It seems one of the major gripes with the approach of not using classes, is that unless *everyone* in the team is ‘on-board’, it’s going to be a very painful and long ride.

    But I do love the idea and I think it’s possible to accomplish regardless of how complicated the project is – it’s all about management of the project.

    If anything, it’s worth taking home the lesson that at the very least, the amount of classes could be cut down substantially – call it a hybrid approach – for complex designs.
    It may be as simple as a single semantic ID on the body that provides the only hook needed to vary layouts without requiring any other classes in the document.

  215. 215

    whow !
    gave up reading comments after many, very interresting.

    I understand the approach and i often use all kinds of selector when starting styling my HTML.
    But that is to see and check rapidly that globaly the CSS technics i use are fine and can leave together, most of the time it remains so for single test pages or poor content.

    Very fast i add my first ids, when html tags are to redundants to just have a meaning by themselves: -> context of course, and that makes it easier to share or let someone else take over sometimes. It helps to structure the style sheet.

    Then of course classes are showing up, cause redundant structure are reusable objects and selectors can still skip them -> structure context again.

    Using CSS selector is fun and that’s what they are made for.

    I agree with the idea,
    I disagree cause
    – it’s just not the way it can work,
    – users are not one kind,
    – teams need easy ‘n understable language rules,
    and HTML attributes are to be used.

    ‘back to the future, folks !’ :)

  216. 216

    forgot to say that ids, class, … are hooks too to CSS and javascript for example (as someone else said it before).

  217. 217

    Mark, have YOU ever worked on a large and complex project as part of a team WITHOUT using classes?


    Until then, you and the other haters here should put a sock in it and reread Heydon’s article until you actually understand the idea in more detail.

    Here’s a challenge for you, give his ideas a fair shot in 10 small to medium-sized projects where YOU control things. Then come back here and give a PROPER argument.


    … *waits for the penny to drop* …

  218. 218

    I suspect a lot of the hostility in the comments is probably down to the unwillingness to change. You guys are used to your way of working and perhaps some of you have a certain loyalty to other methodologies.

    But why shoot Heydon down? His article is limited in scope, and you’re making that decision there and then that his idea won’t scale or will otherwise be too difficult to implement? That’s just ridiculous. His article is just an introduction! You need to test his idea in various real-life projects before you shoot Heydon down. Implementing, testing and making required changes along the way is the only way we can create something that works well for everyone who chooses to use it.

    He isn’t saying that his way is the only way. But HTML and CSS are not unchanging and our ideologies and methodologies need to evolve with these languages.

    In principle, I understand what Heydon was talking about, and I’m looking forward to implementing and testing it in my projects. Maybe he isn’t 100% on target but he’s got my respect here because unlike the rest of you, he’s trying to solve a problem many of us have experienced. He didn’t deserve the bashing he got.

  219. 219

    I completely agree with you, and love the metaphor you used. Thanks for your contribution to this comment thread.

  220. 220

    I’m just a bluecollar website designer, much of the article and commentaries are over my head. However, what is not lost on me is the importance of building a clear, solid foundation, and keeping a structured, uncluttered form. What Heydon is introducing here is just that.

  221. 221

    Janis Kamburoglu

    July 23, 2013 5:08 am

    Hi, reading this, you must yourself very well know that there are things you can never achieve without using those “classes”. I find the point in minimizing the classes as much as one can. No offence – U can be hundred times better web developer than me – but the blog, how this can be an example of your post is unclear to me – it looks like empty, yet it is so hard to see through it. ? Maybe use classes?

  222. 222

    Tristan Slater

    August 7, 2013 3:21 pm

    This is something I have tried to do as much as I could for a long time, but there really are some cases where classes are necessary, not just common practice, but necessary.

    I haven’t exhaustively read the comments (there are just so many), but the amount I did read, I saw a lot of mention of “real world”, but only in terms of “real world” common practices, not “real world” limitations of CSS. For example, if I want to add an arrow to menu items that have child ‘s I have to add a class .has-children to style them. CSS does not have a “has-children” selector (though it should), so what would I do without classes?

    So, even though I agree with the principle and believe it should be practiced as much as possible, CSS imposes certain limitations, some of which can be fixed with classes.

  223. 223

    I would say I agree with this 50%. There was a time when I very much suffered from “class-itis” (as a result of div-itis) because I thought they were the best thing since sliced bread but soon after experienced how hairy that became to maintain and update the HTML.

    So then I went in the exact opposite direction and tried no classes at all, as Heydon proposes here, but the hairiness just got transferred over to difficulty in maintaining the CSS.

    The new sectioning tags in HTML5 are certainly a leap forward in helping to move us away from div-itis, but classes are still necessary in cases where more specificity is needed.

    I’m now at a point where I try to do as much as I can using only plain tags, and add classes generally when I’ve run out of options for tags. I feel it’s a balanced approach vs going to the extreme of either over-classing or ditching classes altogether.

  224. 224

    Erik Eckhardt

    October 15, 2013 3:16 pm

    Heydon Pickering, your posts in the comments here are all shown with a different background and border color (shades of pink) to indicate that you are the writer of the original article.

    Please explain how you would accomplish this *without* the use of classes. Or would you not do it at all?

    I realize my comment is a bit late to the party and don’t expect an answer, but it would be nice.

  225. 225

    Roberto Góngora

    April 7, 2014 12:26 pm

    I completly agree with this. Your article gave me confidence on such a rabbit hole, and I’m convinced that content do can determine herarchy and structure by itself, and there for set the base for looks, navigation and responsive distribution, not an easy thing to concieve, but I guess it’s just about getting used to think that way.

    Current DOM manipulation, AJAX and HTML5 tags allow to start making versatile documents, that can fit to any template or print stylesheet, just by relaying on a universal and limited tagging convention, instead of on an infinite anarchic classes nesting and naming. I’ll keep on the subject, but I’m with you if you still think we “don’t need classes”, at least not in the main structure, I dare saying classes should only be added dinamically, as selectors or to fit too complicated stylesheets.

    I wonder what your opinion might be almost two years past into the future.

  226. 226

    What this article is still missing is links to actual examples of small and large websites built using this methodology.

  227. 227

    This article is total nonsense (by someone who has a problem understanding classes?) HTML tags hardly do the job. means nothing but some default style that someone decided were the most common way one wished to present content. Actually, having H tags is a concession to the fact that classes are needed, and having 6 h tags even more concession. Since the h tags are just another way of styling ordinary text with “classes” of font-sizes (again, predefined and fixed by someone who thought they knew in advance what you needed to use and the limits of those needs. Littering markup with a whole lot of exception ‘spans’ is just another way of saying, we need classes that can be used or not used to override someone else’s idea of how we want to express our designs. If you have 5 (or a hundred) different ways you wish to specify the style of paragraphs in your code then, without classes, you’ve got a hunt and find nightmare for every/any change you wish to make, and a maintainability problem that goes on forever. I’m working on a site that needs to display or hide hundreds of different list items depending on other conditions, or weekly changes in external events. Simple classes of “on” or “off” on those li makes the job a cinch. Can you imagine having to go in to every page and hunt down every li to add or remove it just for temporary changes? Nonsense. Double nonsense. If you want to have markup supply the variety of needs (and poetry, my discipline, does not use a some limited, standard, “lexicon” — it’s needs are as rich and varied as any genre of writing, often more so since the peripheral styling is not incidental, it is fully semantic (or, as Mcluhan said, “The medium is the message”. ) To handle all the important nuance of styled text with markup tags invites a jungle of complexity no one needs. Stone-age stuff – not to mention the author’s complete misunderstanding of structuralist and post-structuralist critique and really shouldn’t be throwing around names like Saussure (or Derrida or Barthes…etc.) unless they’ve really read and understood them. Obviously this author does not. “little aesthetic differentiation”? Are you kidding. Every word you use is aesthetically differentiated from every other word — even if you use the same word over and over. Go listen to Lenny Bruce’s “fuck you” routine if you don’t think so.

    The real problem is that code jocks borrowed linguistic terms from disciplines they knew nothing about and without understanding them at all. And what we got for the trouble is their ignorance designed into software languages we use. So now we get into these insane arguments about what is “semantic” and what is not. It’s all bullshit to anyone who even had a 101 class in linguistics or poetics or lit. crit. The big mistake in the early design of css was there were no poets, linguists or anthropologists on board those efforts. If there had been, styling properties would have been far richer and more robust, class employment for more natural and reflexive to actual use, and stupid arguments like this article makes wouldn’t be worth the bandwidth its printed on.


↑ Back to top